Consumer Rights Wiki

JavaScript: Difference between revisions

← Older editNewer edit →
VisualWikitext
Rudxain (talk | contribs)
confirmed, superconfirmed
891 edits
m forgot bold format
Rudxain (talk | contribs)
confirmed, superconfirmed
891 edits
mention missing content and hidden content
Line 19: Line 19:
*'''Lack of transparency''': To optimize network bandwidth, JS code is typically served in [[wikipedia:Minification_(programming)|minified]] form, which makes it harder to understand for humans. This is particularly problematic if the original source is not publicly [[wikipedia:Source-available_software|available]], which is typically the case of [[wikipedia:Proprietary_software|proprietary software]].<ref>{{Cite web |last=Gross |first=Carson |date=2023-09-21 |title=The #ViewSource Affordance |url=https://htmx.org/essays/right-click-view-source/ |url-status=live |archive-url=https://web.archive.org/web/20260228105626/https://htmx.org/essays/right-click-view-source/ |archive-date=2026-02-28 |access-date=2026-03-24 |website=</> htmx ~ Essays}}</ref>
*'''Lack of transparency''': To optimize network bandwidth, JS code is typically served in [[wikipedia:Minification_(programming)|minified]] form, which makes it harder to understand for humans. This is particularly problematic if the original source is not publicly [[wikipedia:Source-available_software|available]], which is typically the case of [[wikipedia:Proprietary_software|proprietary software]].<ref>{{Cite web |last=Gross |first=Carson |date=2023-09-21 |title=The #ViewSource Affordance |url=https://htmx.org/essays/right-click-view-source/ |url-status=live |archive-url=https://web.archive.org/web/20260228105626/https://htmx.org/essays/right-click-view-source/ |archive-date=2026-02-28 |access-date=2026-03-24 |website=</> htmx ~ Essays}}</ref>
*'''Excessive tracking''': JS is much more capable than HTML and [[CSS]]<!-- See "CSS Exfil": https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack-and-defense/ --> '''combined''' to track user behavior.<ref>https://clickclickclick.click/</ref> JS can communicate with almost any server (only limited by [[wikipedia:Cross-origin_resource_sharing|CORS]]) at any time (limited by connection availability), using a plethora of protocols. JS can get hardware information and compute a [[Device fingerprint|fingerprint of the device]], user, or both.<ref>https://privacycheck.sec.lrz.de/</ref><ref>https://abrahamjuliot.github.io/creepjs</ref><ref>https://www.deviceinfo.me/</ref><ref>{{Cite web |title=Learn how identifiable you are on the Internet |url=https://www.amiunique.org/ |access-date=2026-03-19 |website=Am I Unique ?}}</ref>
*'''Excessive tracking''': JS is much more capable than HTML and [[CSS]]<!-- See "CSS Exfil": https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack-and-defense/ --> '''combined''' to track user behavior.<ref>https://clickclickclick.click/</ref> JS can communicate with almost any server (only limited by [[wikipedia:Cross-origin_resource_sharing|CORS]]) at any time (limited by connection availability), using a plethora of protocols. JS can get hardware information and compute a [[Device fingerprint|fingerprint of the device]], user, or both.<ref>https://privacycheck.sec.lrz.de/</ref><ref>https://abrahamjuliot.github.io/creepjs</ref><ref>https://www.deviceinfo.me/</ref><ref>{{Cite web |title=Learn how identifiable you are on the Internet |url=https://www.amiunique.org/ |access-date=2026-03-19 |website=Am I Unique ?}}</ref>
*'''Market control''': JS is built into almost every web-browser and [[wikipedia:User_agent|user-agent]] (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".<ref>{{Cite web |title=Everyone has JavaScript, right? |url=https://www.kryogenix.org/code/browser/everyonehasjs |url-status=live |archive-url=https://web.archive.org/web/20260316024516/https://www.kryogenix.org/code/browser/everyonehasjs.html |archive-date=2026-03-16 |access-date=2026-03-19 |website=Kryogenix Consulting}}</ref><!-- We need another citation here. The current one is relevant, but doesn't cite anyone who assumes JS is portable. Ideally, it should cite an entity using that quote as an excuse to add JS everywhere -->
*'''Market control''': JS is built into almost every web-browser and [[wikipedia:User_agent|user-agent]] (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".<ref name=":0">{{Cite web |title=Everyone has JavaScript, right? |url=https://www.kryogenix.org/code/browser/everyonehasjs |url-status=live |archive-url=https://web.archive.org/web/20260316024516/https://www.kryogenix.org/code/browser/everyonehasjs.html |archive-date=2026-03-16 |access-date=2026-03-19 |website=Kryogenix Consulting}}</ref><!-- We need another citation here. The current one is relevant, but doesn't cite anyone who assumes JS is portable. Ideally, it should cite an entity using that quote as an excuse to add JS everywhere -->
*'''Security risks''': It is well-known that JS is poorly-designed,<ref>https://github.com/denysdovhan/wtfjs</ref><ref>https://github.com/brianleroux/wtfjs</ref><ref>https://github.com/Rudxain/ideas/blob/aa9a80252a4b7c9c51f32eda5c716e96220ed96e/software/evar/with_bf.js</ref> even [[wikipedia:Ecma_International|tc39]] acknowledges that{{Citation needed}}<!-- They do improve (and complicate) it every year, but the fact that `eval` isn't deprecated implies they don't care that much about improving the language -->. This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that ES is [[wikipedia:Turing_completeness|Turing-complete]]<!-- Not typo. ECMAScript alone is TC. No need for extensions --> (both [https://gavinhoward.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#mathematical-vs-practical in practice and in theory]), 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]].
*'''Security risks''': It is well-known that JS is poorly-designed,<ref>https://github.com/denysdovhan/wtfjs</ref><ref>https://github.com/brianleroux/wtfjs</ref><ref>https://github.com/Rudxain/ideas/blob/aa9a80252a4b7c9c51f32eda5c716e96220ed96e/software/evar/with_bf.js</ref> even [[wikipedia:Ecma_International|tc39]] acknowledges that{{Citation needed}}<!-- They do improve (and complicate) it every year, but the fact that `eval` isn't deprecated implies they don't care that much about improving the language -->. This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that ES is [[wikipedia:Turing_completeness|Turing-complete]]<!-- Not typo. ECMAScript alone is TC. No need for extensions --> (both [https://gavinhoward.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#mathematical-vs-practical in practice and in theory]), 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]].


Line 46: Line 46:
{{See also|Bloatware}}
{{See also|Bloatware}}
If a JS [[wikipedia:Web_framework|framework]] is used to dynamically generate the DOM, 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 a JS [[wikipedia:Web_framework|framework]] is used to dynamically generate the DOM, 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.<ref name=":0" /><ref>{{Cite web |last=Luu |first=Dan |title=How web bloat impacts users with slow connections |url=https://danluu.com/web-bloat/ |access-date=2026-04-13}}</ref> 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.<ref>https://github.com/Rudxain/uBO-rules/blob/b1086023e7db98dee55d425edc20722e641dd4b8/rx.abp#L71-L75</ref>


===Scraping===
===Scraping===
Line 78: Line 80:
*[https://grugbrain.dev/ HTMX developer advocating for less JS]
*[https://grugbrain.dev/ HTMX developer advocating for less JS]
*[https://idlewords.com/talks/website_obesity.htm "Web Obesity Crisis"]
*[https://idlewords.com/talks/website_obesity.htm "Web Obesity Crisis"]
*[https://danluu.com/web-bloat/ "How web bloat impacts users with slow connections"]
*[https://tonsky.me/blog/js-bloat JS bloat (2024)]
*[https://tonsky.me/blog/js-bloat JS bloat (2024)]
*[https://tonsky.me/blog/disenchantment How JS makes web apps more unstable]
*[https://tonsky.me/blog/disenchantment How JS makes web apps more unstable]
Retrieved from "https://consumerrights.wiki/w/JavaScript"