You might not want

Recently, many “You Might Not Need ...” thoughts have been popping up on blogs, social media and in talks. A lot of good points have been made by people from both sides, but I feel they miss the real point.

Context

Back when You Might Not Need jQuery was published, I was a fan. At the time, ES5 was released and the Web API received some upgrades, making DOM selection and manipulation a lot easier, which is exactly the reason why the argument was published. The point wasn’t to criticise jQuery, it was to make developers aware that they might not need jQuery.

More recently You Might Not Need JS surfaced, carrying a similar statement, but focused on JavaScript rather than jQuery. Peter van Grieken pointed out that the non-JS alternatives provided aren’t very semantic or screenreader accessible, something you should most definitely keep in mind.

Kitty Giraudel responded with You Might Need JavaScript with some very valid points.

Why Discard JavaScript?

“You Might Not Need jQuery” proves that discussions regarding using libraries and frameworks go way back. The discussion whether we should use JavaScript or not, is relatively new. In both cases, arguments seem similar.

Performance has always been an issue, but we now have arrived at a point we know every few milliseconds can make all the difference in revenue or whatever user interaction you desire. Since we’re bound to network speed, we kind of accepted that performance loss years ago and started looking at things we can control, like filesize. HTML is required to display critical content. A document can work without CSS, but it does make all the difference in success. Most of us therefore consider CSS required. Media such as images and videos, despite consuming most bandwidth by far, tends to stay for a similar reason as CSS. They are believed to engage more, despite performance loss, especially on mobile devices. That leaves us with JavaScript. We can’t cut in anything else, right?

Another argument is accessibility. This can be interpreted as assistive technology like screen readers, but that doesn’t make any sense. Applying DOM manipulation incorrectly, or rather incompletely, is an accessibility issue, but JavaScript isn’t the one to blame. JavaScript can be an issue if we look at accessibility in a broader sense: inclusive design. Is JavaScript disabled? It won’t work. Is one of the libraries blocked by an ad blocker? undefined is not a function/object will gladly stop executing the rest of your JavaScript. Perhaps we could say JavaScript increases risk of failure.

Although these and other arguments are perfectly valid, perhaps you do need JavaScript.

It Depends™

A bit cliché, but as always: it depends. If you want DOM manipulation with thorough browser support, like IE6, I would definitely recommend jQuery. Not using jQuery would mean I would have to consider bugs and browser-specific behaviour I am simply not aware of. If you build an app where DOM manipulation occurs frequently, feel free to use React. If you’re only updating a counter of number of users, I would recommend vanilla XHR. Context is everything. I feel most of these discussions are held where different sides have different contexts in mind. None of the solutions in our industry fits all.

Ironically, some arguments against JavaScript also are arguments in favour of JavaScript. JavaScript allows us to look at the context in which the site or app is in, and load assets, like polyfills or enhancements, only if necessary, resulting in more happy users. With the ServiceWorker API, we can cache and provide offline support which both benefits performance as inclusivity. We can also make complex components more accessible with JavaScript than using a HTML/CSS hack.

Conclusion

JavaScript definitely earns it’s place. Perhaps not in all projects. Sometimes it is appropriate to avoid certain technology.

The “You Might Not Need ...” projects makes us aware what our options are, allowing us to make the right choice in the right context. What users do we deal with? What is their connectivity? What devices and which browsers do they use? Which browsers do we want to support? How scalable should this project be? What is the client’s budget? Will any of this change over time? All these questions and many more can make all the difference in your choices. No one can rightfully criticise you without fully understanding the context. This is both true in web development as in life.