Javascript – How important is graceful degradation of JavaScript

One disables JavaScript in a browser environment because of the following considerations:

• Speed & Bandwidth
• Usability & Accessibility
• Platform Support
• Security

Speed & Bandwidth

A lot of applications use way too much JavaScript for their own good... Do you need parts of your interface to be refreshed by AJAX calls all the time? Maybe your interface feels great and fast when used with a broadband connection, but when you have to downgrade to slower connection speeds, a more streamlined interface is preferred. And switching off JavaScript is a good way of preventing dumb-struck web-apps of refreshing the world every 15 seconds or so for no good reason. (Ever looked at the amount of data Facebook sends through? It's scary. It's not only a JS-related issue though, but it's part of it).

We also tend to off-load more and more of the processing to the client, and if you use minimalistic (or just outdated) hardware, it's painfully slow.

Usability & Accessibility

Not all user interfaces should expressed in a dynamic fashion, and server-generated content might be perfectly acceptable in many cases. Plus, some people simply don't want this type of interfaces. You cannot please everybody, but sometimes you have the chance to and the duty to satisfy all your users alike.

Finally, some users have disabilities, and thou shalt not ignore them, ever!!!

The worst-case scenarios here, in my opinion, are government websites that try to "modernize" their UIs to appear more friendly to the public, but end up leaving behind a big chunk of their intended audience. Similarly, it's a pity when a university student cannot access his course's content: because he/she is blind and his screen-reader doesn't support the site, or because the site is so heavy and requires ad-hoc modern plug-ins that he/she doesn't get to install on that refurbished laptop bought on e-bay 2 years ago, or again because he/she goes back home to another country for the spring break and the local bandwidth constraints cannot cope with the payload of the site.

Not everybody lives in a perfect world.

Platform Support

This point relates to the 2 previous ones and tends to be less relevant nowadays, as browsers embed JavaScript engines that are a level of magnitude more efficient than they used to be, and this keeps getting better.

However, there's no guarantee that all your users have the privilege of using modern browsers (either because of corporate constraints - which force us to support antediluvian browsers for no good reason, really - or other reasons which may or may not be valid). As mentioned by "Matthieu M." in the comments, you need to remember that a lot of people still use lower-quality hardware, and that not everybody uses the latest and coolest smartphone. As of today, there are still a significant portion of people using phones that have embedded browsers with limited support.

But, as I mentioned, things do get better in this area. But then you still need to remember the previous points about bandwidth limitations if you keep polling very regularly (or your users will enjoy a nice phone bill).

It's all very inter-related.

Security

While obviously you could think that nothing particularly dangerous can be done with JavaScript considering it runs in a browser environment, this is totally untrue.

You do realize that when you visit P.SE and SO you are automatically logged in if you were logged on any other network, right? There's some JS in there. That bit is still harmless though, but it uses some concepts that can be exploited by some malevolent sites. It is completely possible for a website to use JavaScript to gather information about some things you do (or did) during your browsing session (or the past ones if you don't clear your session data every time you exit your browser or run the now common incognito/private browsing modes extensively) and then just upload them to a server.

Recent vulnerabilities (working in major browsers at the time) included the ability to gather your saved input forms data (by trying out combinations for you on a malevolent page and recording the suggested texts for each possible starting letter combinations, possibly telling attackers who you are, where you work and live) or to extract your browsing history and habits (A very clever hack doing something as simple as injecting links into the page's DOM to match the color of the link and see if it's been visited. You just need to do this on a big enough table of known domain names. And your browser getting faster at processing JavaScript, this type of thing gets done quickly.)

Plus let's not forget that if your browser's security model is flawed, or the websites you visit don't protect themselves when enough against XSS attacks, then one might use JavaScript to simply tap into your open sessions on remote websites.

JavaScript is mostly harmless... if you use it for trusted websites. Gmail. Facebook (maybe... and not even...). Google Reader. StackExchange.

But yeah sure, JavaScript cannot be that bad, right? And there are scarier things to fear online anyway. Like thinking you're anonymous when you really aren't that much, as shown by the Panopticlick experiment of the EFF. Which is also partly done using JavaScript. You can even read their reasons to disable JavaScript to avoid browser fingerprinting.

All this being said, there might be perfectly good situations where you don't need to bother about supporting JavaScript. But if you offer a public-service website, do consider accepting both types of clients. Personally, I do think a lot of modern web-apps and websites would work just as well using the former server-generated content model with no JavaScript at all on the client side, and it would still be great and possibly a lot less consuming.

Your mileage may vary depending on your project.

This is a business decision rather than a design decision.

There is a cost to providing a version of the website that works without JavaScript (or Flash, or Silverlight). The business has to decide whether the loss in revenue/visitors is worth it or not.

So if it costs $10,000 to do write this version (the number might be on the large side, but it's there for this example only) then will the business recoup that outlay over the lifetime of the site? If not, then don't provide that version.

However, if it only costs $100 to write this version then it would make sense to provide the graceful degradation.

Having taken the business decision to only target JavaScript enabled browsers and expect that your users will have JavaScript enabled then it makes perfect sense to make your application take advantage of those features you now have available. The only thing you will need to do is (like Stack Overflow itself does) is put up a warning that the site won't function correctly if the user hasn't got it enabled.