Check out myAngular article series with live demos and Facebook group Angular - Advanced Topics

Is jQuery still relevant

Torgeir "Tor" Helgevold
- JavaScript Developer and Blogger
Published: Sat Dec 13 2014

As so many other developers I got my first introduction to complex client side web applications through jQuery. It was essentially the gateway drug that got most developers hooked on JavaScript during a time when JavaScript played a relatively modest role in most web projects. I will always be grateful for the productivity boost I got from adding jQuery to my, back then, very limited repertoire of client side skills. However, as project requirements got more and more complicated, developers started to realize that the traditional jQuery pattern of very little separation between object model and markup was not scalable. I think this and a few other factors beg the question, is jQuery still relevant today?

I think there are still reasons, jQuery plugins in particular, to use jQuery as part of your technology stack, but beyond that, I would recommend using it sparingly. I still admire the genius idea and principle behind jQuery, but I find that the biggest problem with the approach is the tight coupling between model and html elements. As most people learn the hard way, this tight coupling becomes a big problem over time. Writing automated tests becomes an uphill battle because of the dependency on the DOM, but it also makes the JavaScript code less flexible and reusable. Other approaches like the MV-X (MVC, MVP, MVVM) patterns solve this a lot more elegantly by encouraging a decoupled data model in tandem with template based databinding.

The tight coupling between the markup and the JavaScript code usually ends up causing bugs over time since no one usually has a clear picture of all the “magic” selector strings in the UI. The selectors typically assume a very specific DOM structure and are brittle if the UI changes even slightly. In a template based model you see less of these bugs since the model is more flexible and doesn't assume a specific DOM tree. With proper decoupling your model will work with several different structures. In fact the true tests of a properly decoupled model is that it's transparent to the model if it's being instantiated by a unit tests or a markup view.

One might say that building a complex JavaScript application on the back of jQuery is going beyond the original intent of the library. I still think it's a brilliant tool for direct DOM manipulation, but as browsers have caught up, and now offer native versions of almost the same thing, isn't fair to ask if even DOM manipulation warrants jQuery?

It used to be that jQuery was needed to avoid writing browser specific JavaScript, but this seems to be less of a problem these days as projects are dropping support for the older most troublesome browsers. Even jQuery is dropping support for legacy browsers, so the browser api normalization argument is probably not as relevant anymore either.

Things have changed a lot in web programming over the last few years, and the JavaScript community has started to embrace patterns and practices that have been common place in server side code for years now. None of the popular patterns promote the tight coupling between view and code introduced by jQuery, so it is my opinion that modern day projects are better served without jQuery.

If you liked this article, share it with your friends on social media:

We also have a new Facebook group about advanced Angular topics.

I invite you to follow me on twitter