Friday, November 5, 2010

How Many Users Support JavaScript?

Graph of percent of users with JavaScript disabled.

This is one of those posts I started back in mid-October and sat on, suspecting that there would be more follow-up, backlash, challenges, and general bickering. There has been some, but then it died down a bit. And then I remembered I should post this.

The Yahoo Developer Network posted an article (by Nicholas Zakas) in mid-October asking the same question I have been asking for 15+ years (and so have many of you, even if not for that long): How many users have JavaScript disabled?

The post goes into some detail outlining the methodology for capturing the data, which is worth reading for the follow-up posts, but here is the breakdown:

After crunching the numbers, we found a consistent rate of JavaScript-disabled requests hovering around 1% of the actual visitor traffic, with the highest rate being roughly 2 percent in the United States and the lowest being roughly 0.25 percent in Brazil. All of the other countries tested showed numbers very close to 1.3 percent.

If you've followed me long enough, you know that I have always (15+ years) argued that sites should and need to function without JavaScript, that JavaScript can then be added on to enhance and improve the experience.

The Yahoo article echoes that sentiment and provides some simple math to prove that point: with 300 million users hitting the Yahoo home page every month, 6 million of them don't have JavaScript. Think about that. Are you willing to turn away that many users with short-sighted development practices?

Mike Davies, a former Yahoo Europe worker, took issue with the message and methodology from the Yahoo post and wrote about it on his blog (Disabling JavaScript: Asking the wrong question). In particular he focused in on this snippet from the original post:

First, the overwhelming majority of users has JavaScript-enabled browsers and can therefore take advantage of all of the enhanced functionality and dynamic interfaces developers and designers love to create.

He doesn't address the second point, that 6 million users hit Yahoo each month without JavaScript. Instead he takes people to task for jumping on the first point as justification to continue their own ill-advised development practices that leave non-JS users in the cold. After all, people tend to find data to support their own opinions and discard the rest (we just had elections in the US that bolster that point). This motivates him to suggest other ways that users might not have JavaScript support in their browsers — a browser cannot execute JavaScript it has not received.

Citing network outages, corporate firewalls, band browser extensions, he notes that some users sometimes never receive the code. He goes on to point out poor coding can prevent script from even executing, ranging from browser detection, object detection, poor error handling, and so on. These users wouldn't show up in the Yahoo test as JavaScript-incapable, even though they functionally are.

The author of the original Yahoo post had an addendum to help address the comments received on the first post along with all the other chatter around the web and wrote Followup: How many users have JavaScript disabled?. In it he reviews his methodology for arriving at the numbers in the original post. While I don't agree with some of the assumptions he makes, it doesn't diminish the percentages from the original post and only leaves room for them to be higher.

The rest of the post goes on to expand on one of his points from the first post, that a small percentage of a large number is still a large number. He goes on to outline and defend the Yahoo development approach and outline Yahoo's use of progressive enhancement. Yahoo's own research validated the assumption many of us make, that users do surf without JavaScript.

The takeaway from this entire back-and-forth is that there are still users without JavaScript support, for a variety of reasons, and they are a significant number of users. Neglecting them as you build web sites and applications is short-sighted and just bad practice. This has been true for over 15 years, so it's reasonable to expect it will be true for years to come.

Update: February 11, 2011

I discuss how assuming everyone has JavaScript is probably a bad idea, especially when your JavaScript breaks: Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea.

Updated: October 22, 2013

The UK Government Digitial Service outlines how it tracked users who aren't able to use JavaScript (regardless of reason), which turns out to be tricky: How many people are missing out on JavaScript enhancement? Note the numbers 3 years on aren't much different from Yahoo's own numbers suggesting perhaps there will always be a 1%.

Update: May 7, 2015

It's 2015 and yes, this is still a thing. So I'll just leave this here for your review: Everyone has JavaScript, right?

2 comments:

  1. I can't accept your conclusion. Given that development time is infinite, I agree. But development time is very, very finite.

    You choose, then, to put time into the 2% that don't have JS. I choose to put the same time into making a better site for the 98% that have JS.

    ReplyDelete
  2. I think you have it backward. Any functional public-facing site must not rely on client-side script to accomplish all its core functionality. For example, if you are doing forms validation, it must still be handled on the server or some combination of non-JS-capable browsers, users who like to "hack" forms, and spam bots will break them. I can't imagine you wouldn't trap for SQL injection attacks on the server. That's just standard development practice.

    This standard and best practice also happens to support your non-JS users.

    To then add user-friendly form validations, messages and tips in JavaScript is an enhancement -- an enhancement that improves the user experience from the standard support.

    I can tell you from 15+ years of practice, this does not increase development time.

    If you are putting time into building support for non-JS users, then your development process may be going in the wrong direction.

    ReplyDelete