JavaScript

❗Article Status Notice: Inappropriate Tone/Word Usage

This article needs additional work to meet the wiki's Content Guidelines and be in line with our Mission Statement for comprehensive coverage of consumer protection issues. Specifically it uses wording throughout that is non-compliant with the Editorial guidelines of this wiki.

Learn more ▼

How You Can Help: If this is a non-Theme article (See: Article types):

• Persuasive language should not be used in the Wiki's voice. Avoid loaded words, or the causing of unnecessary offense, wherever possible.
• No direct attacks on named individuals or companies. Malice may be attributed to bad and proven offenders, but only through the use of quotation and citation - never in the Wiki's voice.

If this is a Theme article:

• Where argumentation is used make sure it is clear and direct but not inflammatory. Avoid strong language, or causing unnecessary offense.
• No direct attacks on named individuals or companies. Malice may be attributed to bad and proven offenders, in a formal and calm manner.

This notice will be removed once sufficient documentation has been added to establish the systemic nature of these issues. Once you believe the article is ready to have its notice removed, visit either the Moderator's noticeboard, or the Discord (join here) and post to the #appeals channel.

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).

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.
• 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". John Gruber says that JS shouldn't be part of browsers; one way that would work is by turning JS into an extension or plug-in that the user willingly installs.
• 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.

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

Many webpages (and even entire websites), force the user to keep JS enabled, otherwise they break or deliberately refuse to work. In 2026, considering the advancements in HTML and CSS technology, there is minimal reason why an average website (excluding real-time simulations and low-latency gaming) would ever need JS. The main valid justifications are:

• Legacy code-bases. As those are impractical to migrate to no-JS solutions
• Static web-hosting. As the developer has no control over the server, any interactivity must be provided by JS
• Instant messaging (self-evident)

Expanding on the tracking capability, JS makes it harder for ad-blockers to block ads, since it can be used to make overly-dynamic ads. 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).

Expanding on the security risks, these are the most common vulnerabilities found in JS code:

• 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.

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.

JS not only makes pages "dynamic", the language itself (ES) is very dynamic, which is hard to optimize by engines. To put into perspective how much JS can slow down rendering, someone bench-marked a bloated pure-HTML page and a "simple" React app, the bloated HTML had faster FMP.

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.

List of sites refusing to work without JS

The following is a non-exhaustive list of websites where most or all pages deliberately only work with JS enabled, even when its use is "illegitimate":

• YouTube
• Facebook. It used to work without it, but at some point it became mandatory. Some people claim that it's possible to use without JS when visiting the "lite" or "mobile basic" variants.^{[citation needed]}
• Instagram
• Twitter. It also used to work without it, but some time after being bought by Elon Musk, it became mandatory.^{[citation needed]}
• Bluesky:
  • The web app (bsky.app) shows this message if JS is disabled

    This is a heavily interactive web application, and JavaScript is required. Simple HTML interfaces are possible, but that is not what this is.

    which is questionable
  • Its legal docs (ToS, PP, CG) need JS to be viewed by humans, however this seems more of an oversight than deliberate
• Discord. While its instant-messaging functionality legitimately requires JS, they refuse to let the user change their account settings (including security and privacy ones) unless JS is enabled.

Benefits

It's worth noting that, while JS is trivial to misuse and abuse, JS can enhance the user-experience (UX). The World Wide Web Consortium (W3C) provides comprehensive guidelines for such purposes.

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"
• "Progressive Enhancement Still Important"
• 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"
• "How web bloat impacts users with slow connections"
• 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"
• More sources (TO-DO)

See also

• Electron