JavaScript

🧽🫧Article Status Notice: This Article needs to be cleaned up

---

This article contains sources and content, but is lacking proper format and needs more development to meet the wiki's Content Guidelines and provide a high quality and consistent experience for readers. Learn more ▼

Issues may include:

• The article is not following the correct outline for its subject (i.e. incident, company, product)
• This article contains references that do not utilize the <ref></ref> tags or Cite web template.
• The article has "WIP" mentioned next to content
• A quote longer than two sentences does not use the Quote template.

How you can help:

• Copy and paste the layout from the aforementioned preload templates (depending on the article's topic)
• Take URLs, convert them for the Cite web template, and insert them into the correct sentence where the source can verify a claim.
• Remove personal notes left by editors either with <!-- [text here] --> in source editor or when the article is close to being fully cleaned up.
• Flesh out the article with relevant information

This notice will be removed once the article is sufficiently developed. Once you believe the article is ready to have its notice removed, please visit the Moderator's noticeboard, or the Discord (join here) and post to the #appeals channel, or mention its status on the article's talk page.

⚠️ Article status notice: This Article's Relevance Is Under Review

This article has been flagged for questionable relevance. Its connection to the systemic consumer protection issues outlined in the Mission statement and Moderator Guidelines isn't clear.

Learn more ▼

If you believe this notice has been placed in error, or once you have made the required improvements, please visit the Moderators' noticeboard or the #appeals channel on our Discord server: Join Here.

Notice: This Article's Relevance Is Under Review

---

To justify the relevance of this article:

• Provide evidence demonstrating how the issue reflects broader consumer exploitation (e.g., systemic patterns, recurring incidents, or related company policies).
• Link the problem to modern forms of consumer protection concerns, such as privacy violations, barriers to repair, or ownership rights.

If you believe this notice has been placed in error, or once you have made the required improvements, please visit either the Moderator's noticeboard, or the #appeals channel on our Discord server: Join Here. There may be a discussion about this article on its talk page.

JavaScript

Basic Information
Release Year	1995
Product Type	Software
In Production	Yes
Official Website	https://openjsf.org/

JavaScript (JS), not to be confused with ECMAScript (ES), is a programming language and core technology of the Web, alongside HTML and CSS. It was created by Brendan Eich in 1995. As of 2025, the overwhelming majority of websites (98.9%) uses JS for client-side webpage behavior. It's even used on the server-side (see Node.js).

JS is also known to enhance the user-experience (UX). The World Wide Web Consortium (W3C) provides comprehensive guidelines for such purposes.

For the entirety of this article (unless stated otherwise) the terms "JavaScript" and "JS" will be defined as "ECMAScript with access to Web APIs" or "ES+WebAPI" for short.

Consumer impact summary

• Degraded accessibility: Dynamic and/or active content is well-known to have poor accessibility for users with visual and/or cognitive impairments. While standards such as WAI-ARIA were created to mitigate this, it's no silver bullet, especially when developers aren't aware of ARIA.
• Degraded compatibility: While HTML and CSS degrade gracefully, meaning web browsers not supporting a certain feature will simply ignore it and load the rest of the page, JavaScript does not. If any JavaScript feature is not supported by a web browser and not caught using a try...catch block, the rest of the script is not executed, which usually breaks the entire site if it requires JavaScript for basic functions, as "web apps" usually do. This makes accessing a website impossible from legacy systems that do not support recent web browser versions or minimalist web browsers that challenge the Google-Mozilla duopoly, rather than being able to use some parts of a website.
• Lack of transparency: To optimize network bandwidth, JS code is typically served in minified form, which makes it harder to understand for humans. This is particularly problematic if the original source is not publicly available, which is typically the case of proprietary software.
• Excessive tracking: JS is much more capable than HTML and CSS combined to track user behavior. JS can communicate with almost any server (only limited by CORS) at any time (limited by connection availability), using a plethora of protocols. JS can get hardware information and compute a fingerprint of the device, user, or both.
• Market control: JS is built into almost every web-browser and user-agent (UA), including "light-weight" ones (such as w3m), incentivizing companies to use it for everything, since "there's no need to worry about compatibility or portability".
• Security risks: It is well-known that JS is poorly-designed, even tc39 acknowledges that^{[citation needed]}. This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that ES is Turing-complete (both in practice and in theory), makes debugging and reverse-engineering impractical in big code-bases. It's worth noting that tooling, such as TypeScript and ESLint, exist to substantially minimize the likelihood of bugs.
• Degraded performance (web apps): "Web apps" load slower than traditional web sites because lots of code has to be processed by the web browser before any content can appear on screen, putting the content at the end of the rendering path.

How it works

Whenever a user visits a webpage, an average web-browser will execute the JS code it finds in <script> tags. This code could do anything from updating part of the DOM-tree only when the user requests it, to showing a popup/popunder.

When JS tries to access a "privacy-sensitive" API (such as the microphone) the browser pauses it until the user has granted access for the first time. This is typically done on a per-domain basis. However, as mentioned earlier, many other APIs don't need to ask permission before fetching data.

It's worth noting that JS has a privileged position, relative to Wasm, because of its first-class access to Web APIs.

Why it is a problem

Tracking

Many webpages (and even entire websites), force the user to keep JS enabled, otherwise they break or deliberately refuse to work. CSS stylesheets combined with HTML should be fine with most basic websites/webpages that do not need complex client-side interaction or low-latency server communication.

The data collected by malicious JS makes it trivial to serve personalized ads, even across unrelated sites. Some sites collect so much data that they are indistinguishable from spyware (see also key-logging).

Security

Browser-engine developers (such as Google and Mozilla) not only feel compelled, but are financially incentivized to optimize JS to its limits. This leads to complex code-bases that are harder to verify for correctness. Browser vendors mitigate this via sandboxing. Unfortunately, since modern browsers compile JS to native CPU code (see JIT) to improve performance, this introduces a higher risk of sandbox-escape. Some examples of this are as follows:

• XSS, which NoScript tries to mitigate
• Arbitrary code execution and code injection. Typically caused by eval (part of ES), but there are Web APIs (such as setTimeout and setInterval) that can be misused as well.
• Remote code execution. This is used by hackers and crackers to build bot-nets for DDoS or crypto-mining, but it's mostly used for spyware since it can hide more easily.

Performance

See also: Bloatware

If the DOM-tree is dynamically generated by JS (such as frameworks), the user must wait longer before the browser can display content. This is because HTML+CSS can be parsed and rendered incrementally (immediately as the bytes arrive to the client), while JS must (typically) be completely parsed and then executed.

If the JS fails to load for any reason, the user is left with no content. If the page relies on JS to display content from the main document, the browser will waste bandwidth and time downloading data that won't be shown to the user; this is the case of sites with "splash screens" or "spinners" that use CSS to hide content until it's "ready to be seen" and then un-hidden by JS.

Scraping

Main article: Artificial intelligence/training

Since the rise of big LLM's many brokers have started offering scraping services for companies that want more training data for their AI. And to that end, a lot of headless browser agents have begun to scrape (collect a sites information provided) even with the site's robots.txt provided as a common standard to tell agents not to do so. This has lead to many forums and websites that had not used JS before to start implementing CAPTCHAS (or Anubis), to prevent increased overhead and bandwidth costs.

Incidents

This is a list of all consumer-protection incidents related to this technology. Any incidents not mentioned here can be found in the JavaScript category.

Google Search requires JS (2025)

In January 2025, Google's web-search engine mandates that user-agents must have JS enabled. Google's justification was that it's a defense mechanism against abusive bots (see also Deceptive language frequently used against consumers). However, some people claim that it's an invalid justification.

Proposals and alternatives

• Extension: turning JS into an extension or plug-in, so that users can choose to install it, is a way to discourage abuse and incentivize static/passive pages. To do this, JS must be deprecated as a Web Standard, but not deprecated as language or API.
• Deprecation: John Gruber says that JS should never have been added to browsers. The Gopher and Gemini projects advocate for a simpler web. If JS were to be completely removed from the web, this would allow users to navigate without worrying about invisible tracking. Even if not all JS was removed, this would allow tools like uBO to adapt their filters for non-JS users.
• Feature-freeze: There has been discussion about feature-freezing JS so that it becomes "JS0" (for lack of better name). The main purpose is to make it easier for browser implementers to keep browsers secure and stable.

External links

• LibRedirect explaining why it exists, and how Google Chrome's MV3 limits it
• Google being anti-competitive towards Firefox: https://github.com/uBlockOrigin/uBlock-issues/discussions/3240
• Websites that nag users to enable JS, even when it provides negligible value
• Discord being extremely bloated to the point of crashing when opening Developer-tools: https://github.com/Rudxain/uBO-rules/blob/42220bd4f80052ee15136dff7269df19529c43ec/rx.ubo#L3-L19. This is not the fault of bloated JS, it's likely a bloated DOM-tree, but discord only bloats the DOM when JS is enabled.
• "Enough with the JavaScript already!"
• "Maybe we could tone down the JavaScript"
• "You really don't need all that JavaScript, I promise"
• https://gomakethings.com/why-progressive-enhancement-still-matters/
• https://www.viget.com/articles/the-case-against-progressive-enhancements-flimsy-moral-foundation
• "Shipping a button in 2026…", by Kai Lentit. This illustrates the burnout and fatigue software developers can experience on a daily basis
• HTMX developer advocating for less JS
• "Web Obesity Crisis"
• JS bloat (2024)
• How JS makes web apps more unstable
• GNU/FSF explaining why JS takes freedom away
• GNU/FSF explaining why "web apps" shouldn't exist. WARNING: contains overzealous claims! (according to Rudxain). Related: Local-first
• "I Used The Web For A Day With JavaScript Turned Off"
• "How Much of the Web Actually Work Without Javascript"
• Blog-post with more sources