Editorial: Is JavaScript Always the Best Solution?

This is the editorial from my latest JavaScript newsletter, you can subscribe here.

Lately, there has been a lot of discussion surrounding the role of JavaScript in modern web pages and web apps. It all seems to have kicked off with an amusing (but not entirely untrue) article entitled How it feels to learn JavaScript in 2016 in which the author expresses his concern at the fragmented state of the JavaScript ecosystem and the amount of tooling necessary to start a JavaScript project today.

In the debate that followed, there was an interesting Twitter poll that caught my eye. It asked if in 2016, it’s OK to build a website that doesn’t work without JavaScript. Of the 4,157 people that replied, 42% (so 1,746 people) declared that it was. Woah!

As editor of SitePoint’s JavaScript channel you might expect me to be among those 42%. Well, sorry to disappoint, but I’m afraid I’m not. As my colleague Patrick recently pointed out, it all depends upon the context. Keeping an open mind as to the most accessible and most reliable method of solving a problem, will inevitably lead to the best solution. Here’s a small example to illustrate the point:

Some time ago, I was helping someone on SitePoint forums make a product comparison page, where a user could select multiple products, click a button and be presented with the relevant product specs. The person I was helping had already built the page and the products were marked up as list items (<li> elements) in an unordered list.

My initial solution was to add a hidden <input> element to the page and use that to pass the selected items to the server. I coded up this solution, it worked fine and everyone was happy … that is until I bumped into another forum user called PoPSiCLe. Here’s what he had to say about using JavaScript for the job (edited to remove the expletive):

*headdesk* I can’t even… no, sorry. I can’t. Do people actually make code like this?

“A bit harsh,” I thought, but inquiring as to what the problem was, revealed a much neater solution I had overlooked completely. Namely, to add a checkbox and a label to each <li> element, then to use the adjacent sibling selector (input:checked+label) to style the user’s selection and absolute positioning to hide the checkbox itself. Not a single line of JavaScript was necessary, making the solution more accessible by default! Here’s a demo of what we ended up with for anyone that’s interested.

It’s a small (and somewhat contrived) example, but it serves well to illustrate the point. Just because you can do something with JavaScript, doesn’t necessarily mean you should. Keeping an open mind as to the best tool for a job, will not only lead to the most accessible and robust solution, but means you might also learn a thing or two along the way. This is also the reason that I welcome all of the debate around JavaScript’s position on the web today.

But what do you think? In 2016, is it OK to build a site or an app that only works with JavaScript enabled? Do you do progressive enhancement? Let me know in the comments below.