Published in Technology on A Place For My Head. Tagged , , , & .

There are many legitimate cases for requiring JavaScript to be enabled.

(pauses to think of some)

I kid, I kid. I wouldn’t expect you to build some sort of JS-less version of Google Maps or the Geenes colour tool. You could probably do 80% of it without JavaScript, but you’d hate yourself for it and so would your users hate you. Besides, the remaining 20% is where the majority of the value of the application comes from.

No, websites that use JavaScript to create dynamic, interactive applications are not the problem. Let me instead point you at a few pages you might visit after disabling JavaScript:

What do all of them have in common? Their primary function is displaying static text you can read,[1] and they all show blank pages or loading screens without the aid of JavaScript.

Of course, other pages break without JavaScript in different ways, mildly or drastically. For example, many pages won’t run syntax highlighting on code blocks without JavaScript. Many Medium articles use GitHub to host their code snippets, which won’t load at all without JavaScript. Every website is a unique snowflake that breaks in special ways by trying to reinvent the entire browser.

Others have already explained at length why you can’t rely on JavaScript to work and why it’s not just the small percentage of your users with JavaScript disabled who are affected. I’ll spare you a poor paraphrasing of their words. Instead, I’ll keep it simple.

If your site can’t show me static text without JavaScript, you need to fix it.

A positive counter-example

As a contrast, consider A Viral World (and please ignore the desperate need for design work). I built it with the latest HTML, JavaScript, and CSS features. It’s a laser-focused site whose entire raison d’être is user-submitted audio recordings. I even used one of the latest JavaScript frameworks[2] to create the frontend. So it must require JavaScript, right?

Wrong! The only aspect of it that requires JavaScript is recording a reply through your microphone.[3]

We’re easily able to do it this way because Sapper actually cares about server-side rendering. Everything that can be rendered on the server, is. The parts that require JavaScript actually require JavaScript. And that’s with a completely dynamic site! There’s no excuse for blog posts to require JavaScript to display.

Aside: Keep. Your. Bundle. Sizes. Down.

There is no reason why anyone should have to wait for 2 MB of JavaScript to download and be parsed (because the parser doesn’t care how efficiently you compress the megabytes) before they can desperately hunt for read the words in your article, UX Collective:

2 MB of JavaScript (600 KB compressed) and a load time of 6.41 seconds.

No one wants to see a blank page for three seconds when they hit reload.

Chrome’s Dev Tools show the page taking about 3 seconds to show the first flash of content, which moves out of the way 1.5 seconds later.

These measurements were taken on a 150 Mbps fibre connection. If I use Chrome’s ‘Slow 3G’ setting, the first flash of content is at the 35-second mark. The page dies of sheer exhaustion finishes loading at the 150-second mark. Is this the experience you want your visitors to associate with you?

  1. Though the UX Collective essay does use JavaScript to do fancy things like animate text and images after roughly every sentence, so that you’re never in any danger of having a pleasant reading experience. There’s even a section within the article that keeps reminding you to ‘Keep scrolling’. What a ride.↩
  2. That’s not meant to be disparaging. Svelte and Sapper are what was missing from frontend development. They clearly point the way forward.↩
  3. The really problematic part is that we don’t have any way to provide captions for the user-generated recordings, so hearing-impaired users are left out in the cold.↩