{"id":830,"date":"2015-12-27T17:16:22","date_gmt":"2015-12-27T17:16:22","guid":{"rendered":"http:\/\/ashton.codes\/blog\/?p=830"},"modified":"2016-11-27T18:46:53","modified_gmt":"2016-11-27T18:46:53","slug":"when-do-i-need-a-non-javascript-solution","status":"publish","type":"post","link":"https:\/\/ashton.codes\/when-do-i-need-a-non-javascript-solution\/","title":{"rendered":"When do I need a non-JavaScript solution?"},"content":{"rendered":"

The short answer to “when do I need a non-JavaScript solution”? Always. The long answer? Keep on reading…<\/em><\/p>\n

When I test a new feature built by another developer in my team, one of the first things I do is to turn off JavaScript and see what happens.<\/p>\n

Developers often act surprised at this, and look at me disdainfully for inevitably breaking their\u00a0application when I choose to access it in this way. “This is a client-side calculator! Of course<\/em> it’s going to break without JavaScript!”<\/p>\n

Similarly, when I\u00a0sit in on meetings with developers and stakeholders discussing\u00a0what they\u00a0are hoping to build, “fallback images” and non-JavaScript solutions are often treated as a bit of an afterthought.\u00a0When I put forward the question of fallbacks, it doesn’t surprise me when the answer is a smirk and a “well, I suppose we’d better give IE8 something<\/em>“.<\/p>\n

We’ve all become so used to modern\u00a0browsers and increasingly powerful mobile devices that the concept of a non-JavaScript solution seems an unnecessary extra effort; an additional burden on designer and developer alike. After all, the actual proportion of users who access the website without JavaScript enabled is never more than a\u00a0couple of percent.<\/p>\n

However, ignoring fallbacks\u00a0due to the low\u00a0percentage of\u00a0users most affected\u00a0is short-sighted and is\u00a0missing the point.<\/p>\n

We’re all non-JavaScript users<\/h2>\n

You may have looked at the\u00a0proportion of users who access your website with JavaScript turned off through no fault of their own (e.g. corporate users of IE8) or deliberately (self-aware tech-savvies who are sick of being tracked with cookies) or who don’t even have JavaScript available in the first place (anyone using increasingly popular proxy browsers for reduced data consumption). The combined total of these users might be a tiny proportion of your overall users. Heck, it might even be zero.<\/p>\n

This is no excuse for ignoring your non-JavaScript implementation. Why?\u00a0To paraphrase\u00a0somebody on Twitter:<\/p>\n

“Every user is a non-JavaScript user until the JavaScript loads.”<\/p><\/blockquote>\n

We’re not all on fiberoptic broadband connections. If you’re on a mobile phone on the train and you’re about to enter a tunnel, you’ll be stuck with whatever content arrives in the few kilobytes you managed to download before the signal cut out. Which\u00a0would you rather see: a sea of whitespace and badly formatted text\u00a0accompanied by nothing but the prospect of a seven-minute data vacuum, or the\u00a0core article text with some basic but sufficient\u00a0styling?<\/p>\n

Varying degrees of non-JavaScript solutions<\/h2>\n

Non-interactive\u00a0features (such as datapics<\/a>) have no interactive element and thus should get the core content, untainted by “Turn your JavaScript on!” messages. The content of the feature should be accessible and readable without jumping through hoops.\u00a0Perhaps it’s not possible for the content to look quite as polished as the JavaScript version (though if we’re disciplined about using CSS for presentation and JavaScript only for interaction, this should not be the case).<\/p>\n

Some features, such as quizzes, require client-side interaction to be of any real benefit to the reader. Is a non-JavaScript solution necessary, or even viable?<\/p>\n

When it comes to content where advanced functionality is<\/em> the core content, I still expect a few things for non-JavaScript browsers:<\/p>\n