Emayeah (talk | contribs)
added logo
Rudxain (talk | contribs)
weird but useful mish-mash of theme and product templates
Line 11: Line 11:
'''[[wikipedia:JavaScript|JavaScript]]''' ('''JS''') is a [[wikipedia:Programming_language|programming language]] and core technology of [[wikipedia:World_Wide_Web|the Web]], alongside [[wikipedia:HTML|HTML]] and [[wikipedia:CSS|CSS]]. It was created by [[wikipedia:Brendan_Eich|Brendan Eich]] in 1995.<ref>https://exploringjs.com/es5/ch04.html</ref> As of 2025, the overwhelming majority of [[wikipedia:Website|websites]] (98.9%) uses JS for [[wikipedia:Client_(computing)|client]]-side [[wikipedia:Web_page|webpage]] behavior.<ref name="deployedstats">{{cite web |title=Usage Statistics of JavaScript as Client-side Programming Language on Websites |url=https://w3techs.com/technologies/details/cp-javascript |access-date=2024-02-27 |website=W3Techs }}</ref> It's even used on the [[wikipedia:Server_(computing)|server]]-side (see [[wikipedia:Node.js|Node.js]]).
'''[[wikipedia:JavaScript|JavaScript]]''' ('''JS''') is a [[wikipedia:Programming_language|programming language]] and core technology of [[wikipedia:World_Wide_Web|the Web]], alongside [[wikipedia:HTML|HTML]] and [[wikipedia:CSS|CSS]]. It was created by [[wikipedia:Brendan_Eich|Brendan Eich]] in 1995.<ref>https://exploringjs.com/es5/ch04.html</ref> As of 2025, the overwhelming majority of [[wikipedia:Website|websites]] (98.9%) uses JS for [[wikipedia:Client_(computing)|client]]-side [[wikipedia:Web_page|webpage]] behavior.<ref name="deployedstats">{{cite web |title=Usage Statistics of JavaScript as Client-side Programming Language on Websites |url=https://w3techs.com/technologies/details/cp-javascript |access-date=2024-02-27 |website=W3Techs }}</ref> It's even used on the [[wikipedia:Server_(computing)|server]]-side (see [[wikipedia:Node.js|Node.js]]).


==Consumer-impact summary==
== Consumer-impact summary ==


*'''Forced requirement''': 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 only valid justification are [[wikipedia:Legacy_code|legacy code-bases]], as those are impractical to migrate to no-JS solutions.
*'''Forced requirement''': 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 only valid justification are [[wikipedia:Legacy_code|legacy code-bases]], as those are impractical to migrate to no-JS solutions.
Line 19: Line 19:
*[[Personalized Ads|'''Targeted ads''']]: JS makes it harder for [[Ad block|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.
*[[Personalized Ads|'''Targeted ads''']]: JS makes it harder for [[Ad block|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.
*'''Market control''': JS (alongside [[wikipedia:WebAssembly|Wasm]]) are built into almost every web-browser and UA, including "light-weight" ones (such as [[wikipedia:W3m|w3m]]). Incentivizing companies to use it for everything, since "there's no need to worry about compatibility or portability". Some people say that JS shouldn't even be a Web Standard,<ref>https://daringfireball.net/linked/2017/06/22/navistone-form-data</ref><ref>https://daringfireball.net/linked/2017/06/27/web-without-javascript</ref> implying that it should be an [[wikipedia:Browser_extension|extension]] or [[wikipedia:Plug-in_(computing)|plug-in]] (such as Java Applets and [[Adobe]] Flash) the user willingly installs; this would reduce the incentive to use JS, as there's no guarantee the user has it.
*'''Market control''': JS (alongside [[wikipedia:WebAssembly|Wasm]]) are built into almost every web-browser and UA, including "light-weight" ones (such as [[wikipedia:W3m|w3m]]). Incentivizing companies to use it for everything, since "there's no need to worry about compatibility or portability". Some people say that JS shouldn't even be a Web Standard,<ref>https://daringfireball.net/linked/2017/06/22/navistone-form-data</ref><ref>https://daringfireball.net/linked/2017/06/27/web-without-javascript</ref> implying that it should be an [[wikipedia:Browser_extension|extension]] or [[wikipedia:Plug-in_(computing)|plug-in]] (such as Java Applets and [[Adobe]] Flash) the user willingly installs; this would reduce the incentive to use JS, as there's no guarantee the user has it.
*'''Security risks''': JS is well-known for being a poorly-designed tool.<ref>https://github.com/denysdovhan/wtfjs</ref><ref>https://github.com/brianleroux/wtfjs</ref><ref>https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because</ref><ref>https://github.com/Rudxain/ideas/blob/aa9a80252a4b7c9c51f32eda5c716e96220ed96e/software/evar/with_bf.js</ref> This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that JS is [[wikipedia:Turing_completeness|Turing-complete]] (both [https://gavinhoward.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#mathematical-vs-practical in practice and in theory]) is a recipe for disaster, as it makes [[wikipedia:Debugging|debugging]] and [[wikipedia:Reverse_engineering|reverse-engineering]] impractical in big code-bases. The most common vulnerabilities found are:
*'''Security risks''': JS is well-known for being a poorly-designed tool.<ref>https://github.com/denysdovhan/wtfjs</ref><ref>https://github.com/brianleroux/wtfjs</ref><ref>https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because</ref><ref>https://github.com/Rudxain/ideas/blob/aa9a80252a4b7c9c51f32eda5c716e96220ed96e/software/evar/with_bf.js</ref> This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that JS is [[wikipedia:Turing_completeness|Turing-complete]] (both [https://gavinhoward.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#mathematical-vs-practical in practice and in theory]) is a recipe for disaster, as it makes [[wikipedia:Debugging|debugging]] and [[wikipedia:Reverse_engineering|reverse-engineering]] impractical in big code-bases. It's worth noting that tooling, such as [[wikipedia:TypeScript|TypeScript]] and [[wikipedia:ESLint|ESLint]], exist to substantially minimize the likelihood of [[wikipedia:Software_bug|bugs]].
**[[wikipedia:Cross-site_scripting|XSS]], which [[wikipedia:NoScript|NoScript]] tries to mitigate
 
**[[wikipedia:Arbitrary_code_execution|Arbitrary code execution]] and [[wikipedia:Code_injection|code injection]]. Typically caused by <code>[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval eval]</code> (part of the ECMAScript spec), but there are Web APIs (such as <code>[https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout setTimeout]</code> and <code>[https://developer.mozilla.org/en-US/docs/Web/API/Window/setInterval setInterval]</code>) that can be misused as well.
== How it works ==
**Remote code execution. This is used by hackers and crackers to build [[wikipedia:Botnet|bot-nets]] for [[wikipedia:Ddos#Distributed_DoS|DDoS]] or [[wikipedia:Cryptocurrency|crypto]]-mining, but it's mostly used for [[spyware]] since it can hide more easily.
Whenever a user visits a webpage, an average web-browser will execute the JS code it finds in <code><script></code> [[wikipedia:HTML_element|tags]]. This code could do anything from updating part of the page only when the user requests it, to showing a [[wikipedia:Pop-up_ad|popup/popunder]].
**[[wikipedia:Sandbox_(computer_security)|Sandbox]] escape. Modern browsers compile JS to native CPU code (see [[wikipedia:Just-in-time_compilation|JIT]]) to improve performance; this introduces a higher risk of sandbox-escape, as the code can more easily find vulnerabilities to manipulate the engine.
 
About that last point, it's worth noting that tooling, such as [[wikipedia:TypeScript|TypeScript]] and [[wikipedia:ESLint|ESLint]], exist to substantially minimize the likelihood of [[wikipedia:Software_bug|bugs]].
When JS tries to access a "privacy-sensitive" Web API (such as the microphone) the browser pauses it until the user has granted access to that API. 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.
 
== Why it is a problem ==
Expanding on the security risks, these are the most common vulnerabilities found in JS code:
*[[wikipedia:Cross-site_scripting|XSS]], which [[wikipedia:NoScript|NoScript]] tries to mitigate
*[[wikipedia:Arbitrary_code_execution|Arbitrary code execution]] and [[wikipedia:Code_injection|code injection]]. Typically caused by <code>[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval eval]</code> (part of the ECMAScript spec), but there are Web APIs (such as <code>[https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout setTimeout]</code> and <code>[https://developer.mozilla.org/en-US/docs/Web/API/Window/setInterval setInterval]</code>) that can be misused as well.
*Remote code execution. This is used by hackers and crackers to build [[wikipedia:Botnet|bot-nets]] for [[wikipedia:Ddos#Distributed_DoS|DDoS]] or [[wikipedia:Cryptocurrency|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 economically incentivized to optimize JS to its limits.{{Citation needed}} This leads to complex code-bases that are harder to verify for correctness. Browser vendors attempt to solve this via [[wikipedia:Sandbox_(computer_security)|sandboxing]]. Unfortunately, since modern browsers compile JS to native CPU code (see [[wikipedia:Just-in-time_compilation|JIT]]) to improve performance, this introduces a higher risk of sandbox-escape, as the code can more easily find vulnerabilities to manipulate the engine.


==Incidents==
==Incidents==
Line 30: Line 37:


===Google Search requires JS (2025)===
===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]]).<ref>https://techcrunch.com/2025/01/17/google-begins-requiring-javascript-for-google-search/</ref><ref>https://daringfireball.net/linked/2025/01/18/google-search-javascript</ref><ref>https://serpapi.com/blog/google-now-requires-javascript/</ref> However, some people claim that it's an invalid justification.<ref>https://blog.jim-nielsen.com/2025/javascript-required/</ref>
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]]).<ref>https://techcrunch.com/2025/01/17/google-begins-requiring-javascript-for-google-search/</ref><ref>https://daringfireball.net/linked/2025/01/18/google-search-javascript</ref><ref>https://serpapi.com/blog/google-now-requires-javascript/</ref> However, some people claim that it's an invalid justification.<ref>https://blog.jim-nielsen.com/2025/javascript-required/</ref>


==Benefits==
==Benefits==
Line 62: Line 69:


*[[Electron]]
*[[Electron]]
*[[Mozilla]]


==References==
==References==