TL;DR: jQuery is still relevant, due to its massive success and ubiquity. But don't learn it if you're starting out, only if a project requires it. Focus on vanilla JavaScript and a reactive framework instead.

Over the years as I've been as much of a jQuery adherant as anyone. I've written articles on it for various media, even edited a book on one. Everybody loved jQuery; it truly revolutionised JavaScript development.

But as time ticks on and new technologies become available, every so often the question inevitably arises: Is jQuery still relevant? In this article I'll try to answer that, as we enter 2020, while also looking back at what made jQuery so killer for so long.

jQuery: the missing JavaScript API

It's not difficult to see why jQuery was so revolutionary. Initially released in 2006, right in the middle of the browser wars whereby different browser vendors failed to agree on how certain JavaScript and CSS mechanisms should be implemented, it was an instant hit.

Few product slogans could ever claim to be more apt than jQuery's "Write less, do more", because that's exactly what it offered.

JavaScript, though already well on the way to becoming the lingua franca of the internet that it is today, was then still a fairly bereft API. Many things were clunky or required lots of code, and there were baffling gaps in the API. The browser wars also meant you had to do a lot of feature-testing to see which approach to take depending on the current browser.

Write more, do less

So it was that, if you wanted to attach an event, you had to first feature-test to see if you were in IE (attachEvent()) or other browsers (addEventListener()). Want to get an element's computed styles? That'll be currentStyle in IE, or getComputedStyle() in other browsers.

Now, the failure of browser vendors to agree on standard implementations wasn't JavaScript's fault, but the gaps in the API were. You could insert a child element before another element (Element.insertBefore()) but not after it (there was no Element.insertAfter()).

Attempts to iterate over the child nodes of a parent element were fraught with danger because Element.childNodes also returned text nodes, not only "real" element nodes, which was almost never what you wanted (Element.children, which addressed this, appeared a few years later.)

That returns 5, because it counts not only the two p children, but also the three whitespace 'nodes' between, before and after them. So to get just the p children you'd have to iterate over all five and interrogate each one to find out its node type (which would be 1, for element nodes.)

AJAX? Weeeeell then, again it'll depend on the browser. Whether it was IE or not, you had to write a fair few lines of code either way, but via new XMLHTTPRequest() for non-IE browsers and new ActiveXObject() until IE7.

I'm a jQuery developer, me

So this was all great - music to the ears of those of us who daily pulled out our hair at the sheer effort it took to achieve simple tasks in native JavaScript.

The danger, though, was that new developers would learn jQuery exlusively, and never look under the hood. I've worked with many junior devs who, if you take away jQuery from them, are completely stuck.

jQuery's ubituity and sheer usefulness also engenderered false notions among noobs, who still today on Stack Overflow ask questions referring to things like "jQuery array" or "jQuery variable". To them, JavaScript === jQuery. Particularly telling are the questions that ask whether something done in jQuery is possible to do in native JavaScript (the answer being, of course.)

And jQuery was never without its detractors; right from the early days there were plenty who disliked its chaining pattern. Code like the following may be a breeze to write:

But it's not overly descriptive. What's actually going on there? What on earth is addBack()? Doesn't such a disparate range of operations deserve several lines of code, if only for readability?

Enough history; what about today?

It has to be said that jQuery has adapted well. It's a super-well-maintained library and its devs have been fastidious in trimming the fat and keeping jQuery as performant and lightweight as possible.

This's partly the reason why jQuery is still so widely used; one source suggested that, as late as February 2019, jQuery was still being used by a staggering 77% of the world's top million websites, many of whom were using ancient versions of it.

So yes, jQuery is undoubtably still relevant. However, I'm not sure that's the same thing as it being a good idea to learn. The landscape is much changed from jQuery's glory days.

The current state of things

jQuery profited at a time when no single methodology reigned in front-end land. Everyone just hacked away at their DOM, binding events, listening for changes, updating properties and text as they went. This meant a lot of code (even for jQuery) and difficulty of maintenance.

As we've seen, jQuery also profited from the poor state of JavaScript's API back in the day.

But both of these situations are today very different. Today, manually maintaining and updating your DOM is considered old hat. That's why reactive frameworks like Angular, Vue and React exist (and others).

These frameworks have two objects of focus jQuery never had: namely state, and reactivity. That is, how should data persist and be mutated, and how should parts of the DOM be related to - and react to changes to - that data?

And even when you do still need to manipulate the DOM manually, the native API has come a long way, with new additions directly inspired by jQuery equivalents. I'm thinking of how-did-we-ever-do-without-them stalwarts such as Element.querySelector(), Element.matches() and Element.closest().

jQuery's other main strength, AJAX, has also seen major development. We now have the Fetch API, which in its simplest terms is a much less verbose version of XMLHTTPRequest(), and also AJAX-specialising libraries like Axios. Many of the frameworks have their own built-in AJAX APIs too.

Should you learn jQuery?

For my money, no. Or at least, let me qualify that by saying: don't start by learning jQuery. As much as anything, jQuery might well hinder your employment prospects; even in jQuery's glory days employers were nervous about developers who knew jQuery only.

If you're starting out, I'd suggest focusing first on basic JavaScript syntax and examples before then moving on to some of the (excellent) tutorials available for the reactive frameworks. Pick one you're comfortable with; I particularly like Vue.

If you're inheriting a project that uses jQuery, then of course it still makes sense to learn some. But jQuery is so intuitive and easy that this won't take you long. The whole point of jQuery was to be easy to read and write, much easier than the native API in the state it then was.

Did I help you? Feel free to be amazing and buy me a coffee on Ko-fi!