On Supporting JS

Drew McClellan posted on HackerNews that thinking about users with JavaScript disabled is unhelpful. I often put this forward as a reason to build your HTML, then CSS, then JS. While useful to provide stark examples, I agree it gets lost on some people because the case is usually infrequent. I really mean what he describes in that post. Build your frontend code in a way that can handle scenarios where something doesn’t load, or encounters an error. If your layout falls apart because JavaScript isn’t present, or errors on something, that’s not good. Same with something in your CSS. This doesn’t mean we can’t use the new hot thing, but we have to make sure it’s added to a strong foundation, and is not part of the foundation. In other words, your code is progressively enhanced.

Thinking about users with JavaScript disabled is unhelpful. Sure, some of those exist, but they’ve largely opted into that.

It’s more helpful to think about designing a site to work robustly for the situations in which JavaScript doesn’t successfully run. There could be reasons from aggressive firewalls blocking scripts, to slow or broken network connections, where the user might not get your JavaScript along with the page.

Many browsers halt all JavaScript execution on a script error. All it takes is a badly coded third-party ad on your page, or a typo in your own code to stop all JavaScript on the page from running.

Is it right that your page or app should completely stop functioning at that point? The web is a brittle platform. Things break all the time, but our technology stack of HTML, CSS and JavaScript can be exceptionally robust when used in the right way.

Build your site with HTML. Make it look much better with CSS. Make it work much better with JavaScript. Be prepared that CSS or JavaScript may not load at any point, with the reassurance that plain old HTML has got your back.

Sure, it takes a bit longer. Doing a good job always does.

I previously posted about the issues GitHub had when its CDN went down. It still mostly worked but some things didn’t work. It was a good example of how a site responds in those situations and what decisions they make for them.

I think the best method to explain this situation is to help people understand the pieces that go into a website, and places where those things can “fail”, either through not loading, experiencing an error, or other reasons. It’s also helped by approaching our work from mobile first/content first, because we look at page construction differently.