This content originally appeared on Adam Silver and was authored by Adam Silver
There’s been some comments about this on Twitter.
You might have heard that the percentage of users without JavaScript is approximately 1% and that these people actively turn it off. And on that basis that it’s okay to exclude them.
First of all, 1% of a large number is still a large number. A 1% increase in users is not usually something to be sniffed at.
But more importantly, the problem is less about the 1% of users who always visit your site without JavaScript and more about the 1% of visits to your site which result in users experiencing your site without JavaScript. And through no fault of their own.
For Buzzfeed, for example, 1% of visits is actually 13 million requests per month.
Stuart Langridge visualises the difference between 1% of users not having JavaScript versus 1% of visits not having JavaScript in why availability matters.
Crucially, these users don’t turn off JavaScript nor are they using an old feature phone. They’re just like you and me.
Here I’ll jot down all of the reasons users experience sites as if they don’t have JavaScript and at the end I’ll explain what we can do about it.
# 1. The browser doesn’t recognise your JavaScript code
If your JavaScript file contains methods or properties the browser doesn’t understand, the script won’t run.
This happens a lot because every day new browsers come out and new websites are published which rely on new APIs and JavaScript frameworks that will only work in a narrow range of cutting edge browsers.
All it takes is for one method not to be recognised and users experience the site as if JavaScript is off.
# 2. Browser extensions can break JavaScript
Browser plugins use JavaScript to change and add functionality to web pages. But, this is at risk of breaking depending on how well the site’s JavaScript and the plugin’s JavaScript is written.
Specifically, if JavaScript is written without feature detection, it can cause the interface to break.
As a result, users get the ‘JavaScript off’ experience.
# 3. Some browsers turn off JavaScript on slow connections
Chrome on Android, for example, automatically turns off JavaScript on slow connections in order to speed up page load times.
Again, under these circumstance users get the ‘JavaScript off’ experience. So all the links you put inside a hamburger menu will be laid out somewhere (or not at all) depending on your implementation.
# 4. JavaScript might fail to download
Like any HTTP call, the request for your site’s JavaScript can fail to load. This can happen—and has happened to me—on a train because the connection stops before the script is downloaded.
Similarly, Content Delivery Networks (CDN) can go down, so even if your connection is stable, the server responsible for sending back JavaScript might not be.
Intermittent connection or intermittent server means: the user gets the ‘JavaScript off’ experience.
# 5. Corporate firewalls and mobile operators block JavaScript
Some corporate firewalls block or change JavaScript files before they are sent to the browser.
For example, Sky Broadband once accidentally blocked Jquery which caused lots of sites to break. And this is another one I’ve experienced myself—when I worked at T-Mobile they blocked certain scripts to improve performance.
It’s not the users’ fault, but once again they are denied the use of JavaScript.
# 6. Some browsers don’t run JavaScript
Some browsers, such as Lynx, don’t run JavaScript. So if your site shows nothing without JavaScript, then that’s what users will get— nothing.
(And that’s just one of the problems that I noted in my discussion of single page applications.)
# What to do about it
The more your site relies on JavaScript, the more fatal the experience is likely to be when JavaScript is unavailable.
So the first thing to do is follow Tim Berners-Lee’s rule of least power by doing as much work further down the stack as we can.
In other words, if you’re dealing with text, images, video and forms—which is most of us, most of the time—then render the HTML on the server. No JavaScript needed, more robust and more performant.
For the remaining enhancements that genuinely need JavaScript to work, use feature detection to stop browsers that aren’t able to apply the enhancement and therefore breaking the interface unnecessarily.
# Summary
While some users actively turn off JavaScript, the vast majority of users experience an equivalent experience through no fault of their own.
It’s not a matter of if your users don’t have JavaScript—it’s a matter of when and how often.
The answer to that is around 1% of the time.
If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.
The same goes for JavaScript. It’s not about people who turn it off. It’s about the nature of the web itself.
When it fails, it’s our job to make sure we don’t exclude users from accessing the products we make by designing resilient interfaces.
Thanks a lot to Caroline Jarrett for her feedback and suggestions.
This content originally appeared on Adam Silver and was authored by Adam Silver
Adam Silver | Sciencx (2019-11-04T00:00:00+00:00) JavaScript isn’t always available and it’s not the user’s fault. Retrieved from https://www.scien.cx/2019/11/04/javascript-isnt-always-available-and-its-not-the-users-fault/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.