MediaWiki

No-JavaScript notes

This page attempts to document reasons and demographics for no-JavaScript users.

Reasons for not having JavaScript

edit

Unintentional

edit

Users may unintentionally receive the non-JavaScript version, if:

  1. They lost connection to the internet midway through the page-load (especially mobile users, and users with unstable wifi connections)
  2. Some JavaScript code throws an exception during initialization, preventing further code from loading
  3. The user clicks on something on the page that blocks further loading

Intentional

edit

Users may intentionally receive the non-JavaScript version, because:

  1. Security
    1. For security (JavaScript vulnerabilities in browsers)
    2. For privacy (preventing some tracking/advertising systems, usually coupled with disabled cookies)
    3. Corporate proxy disabled it (for intranet security)
  2. Preference
    1. For annoyance prevention (to prevent things like animations, particularly for users who find these overwhelmingly distracting or nauseating)
    2. To avoid downloading and executing software that is not freely licensed (since the JavaScript on some sites may be proprietary)
  3. Performance
    1. For faster site downloading (less to download (bytes))
    2. For faster browser rendering (less to calculate (complexity))

Methods for disabling JavaScript

edit
  1. NoScript, uMatrix, and similar browser extensions
  2. Browser settings (e.g. javascript.enabled option in Firefox)
  3. Connection proxy
  4. A browser that doesn't support it (lynx, etc.)
  5. Developers can use their browser's developer tools to disable JavaScript for specific requests

Tips for developers

edit
  • Use a progressive enhancement approach
  • MediaWiki has client-js and client-nojs classes that CSS can use to target users based on whether JavaScript is run for them. (added in 2011 in T32497)
    • These classes are set on the html root element, so use selectors and display:none to remove something from the page.
  • Use your browser's developer tools to test user interfaces without JavaScript enabled

Metrics

edit

Sources and further reading

edit
  • On Wikipedia:
  • About no JavaScript on Wikipedia:
    • Charlie Owen (2017). "A day without Javascript" (archived). "Like a good friend, Wikipedia never disappoints. The site is indistinguishable from the JS version. Keep being beautiful, Wikipedia."
  • On W3C site:
    • W3C Web Standards Curriculum (2011). "Graceful degradation versus progressive enhancement". "It can be said that both progressive enhancement and graceful degradation try to do the same thing: keep our products useful to every user."
    • W3C Web Standards Curriculum (2011). "The principles of unobtrusive JavaScript". "Before we go on to look at practical JavaScript usage in detail, we need to stop and think about how to use JavaScript sensibly so that it doesn’t exclude anyone from your web site. This is the core idea behind unobtrusive JavaScript."
  • Questions on Stack Exchange Network:
  • On other sites:
    • WebAIM (2003/2013). "Accessible JavaScript". "It is a common misconception that people with disabilities don't have or 'do' JavaScript, and thus, that it's acceptable to have inaccessible scripted interfaces, so long as it is accessible with JavaScript disabled. A 2012 survey by WebAIM of screen reader users found that 98.6% of respondents had JavaScript enabled. The numbers are even higher for users with low vision or motor disabilities. In short, people with disabilities will experience scripting, so scripted content must be made natively accessible."
    • Web Designer Depot (2010). "How to plan for the absence of JavaScript". "When planning your information architecture and design, you must figure out how to deal with these special groups. I have assembled a few recent real-world scenarios to find clarity on the issue."
    • Emma Patricios (2011). "Why we should support users with no JavaScript". "This post aims to give you some reasons why we should still be supporting users without Javascript."
    • Craig Buckler (2013). "Should users be permitted to disable JavaScript?". "Users will always be able to prevent JavaScript running no matter how vendors show or hide advanced settings – but few will bother. Whether we should cater to those users without JavaScript depends largely on the application you are building. Yet common sense dictates: the more accessible your content, the larger the audience you can attract."
    • Peter Herlihy (2013). "How many people are missing out on JavaScript enhancement?". "This isn't about whether we should offer a good service to non-JavaScript people, progressive enhancement, done well, ensures we always will. But it's interesting to know that 1 in 93 people will experience the design without JavaScript enhancement – especially when it comes to prioritising how much of our time to spend on that design."
    • WebAIM (2014). "Screen reader user survey #5 results". "Prevalence of JavaScript being enabled [97.6%] was down only slightly from May 2012 (98.6%). The vast majority of those with JavaScript disabled were using Firefox (presumably with the NoScript add-on enabled) or were using Lynx on Linux."
    • Ynori Seven (2014). "JavaScript disabled: should I care?". "JavaScript was created as a tool to enhance the browsing experience by adding additional behavioral and interactive features. When did we get to the point where lack of this additional functionality meant the entire process should fail? That's like your car refusing to start because you disabled the radio and the air conditioner."
    • Klint Finley (2015). "I turned off JavaScript for a whole week and it was glorious". "There's another web out there, a better web hiding just below the surface of the one we surf from our phones and tablets and laptops every day. A web with no ads, no endlessly scrolling pages, and no annoying modal windows begging you to share the site on social media or sign up for a newsletter. The best part is that you don't need a special browser extension or an invite-only app to access this alternate reality."
    • Mike Gerwitz (2015). "GitHubbub! GitHub does not value software freedom". "Free software guarantees your freedom to study, modify, and share the software that you use. We value these freedoms on the desktop, so why should we compromise when websites serve proprietary JavaScript just because it creates the illusion of remote execution? When you visit a website that serves JavaScript to the client, your web browser is automatically downloading and executing (often without your permission) ephemeral, unsigned, untrusted software. If that JavaScript is not freely licensed, then the software running in your web browser is proprietary."
    • Andrzej Winnicki (2016). "Just how many web users really disable cookies or JavaScript?". "Our results show UK visitors [to Yell.com] almost always allow JavaScript, with only 0.07% of Yell.com users not allowing JS. This would work out to around 14,000 users out of our twenty million sample, which is a small proportion of traffic and won’t have a big influence on how we design new web applications. Of course, that doesn’t mean we will ignore these users, but we can plan our priorities accordingly."
    • Blockmetry (2017). "What percentage of browsers with javascript disabled?". "From Blockmetry’s direct measurements, 0.2% of pageviews from worldwide traffic across all devices in the fourth quarter 2016 had javascript disabled. Although apparently tiny, the aggregate figure hides a lot of interesting variation and regional patterns, with traffic from some countries having much higher JavaScript disabled rates. Further, cross-tabulating by device type, traffic from desktops, Android phones and Android tablets had the highest rates of disabling JavaScript, while iPhones and iPads generally had lower rates. The next question is: Who disables JavaScript at high rates? The answer is Tor users, east Asian countries, Africa, and Finland. A somewhat unsurprising finding is that 10.5% of pageviews from Tor visitors disable JavaScript. Websites that attract sizeable volumes of Tor traffic need to take note."
    • Vue.js (2017). "Vue.js Server-Side Rendering Guide". "Compared to a traditional SPA (Single-Page Application), the advantage of SSR [Server-Side Rendering] primarily lies in: [1] Better SEO, as the search engine crawlers will directly see the fully rendered page. Note that as of now, Google and Bing can index synchronous JavaScript applications just fine. Synchronous being the key word there. If your app starts with a loading spinner, then fetches content via Ajax, the crawler will not wait for you to finish. This means if you have content fetched asynchronously on pages where SEO is important, SSR might be necessary. [2] Faster time-to-content, especially on slow internet or slow devices."

See also

edit
Retrieved from "https://www.mediawiki.org/w/index.php?title=No-JavaScript_notes&oldid=6858477"