Milkman Matty
26/03/2022

jQuery will always have a special place in my heart. Those that can remember trying to develop for the web before its creation will remember the troubles of cross-browser support and shaky JavaScript API implementations. jQuery abstracted away many of the pains of web development into a nice, easy to use, cross-browser API.

Despite exploding onto the scene in 2006 and maintaining a huge adoption since jQuery has started to decline in usage recently. I wanted to investigate why this is and indeed what are the use cases in 2022 for using jQuery.

Why jQuery Was Made - Why it is Useful

When jQuery was made back in 2006 the state of the web was vastly different. The WHATWG initiative of Apple, Google Mozilla and Microsoft had only just formed and was still gaining traction. As such, cross-browser differences were much higher with a greater impact if not accounted for. JavaScript was also not as mature as it is now with a lot of functionality that we take for granted today simply not existing back then.

Easy to forget that JScript was a thing and still existed. Of course there's also the odd learning curve that only exacerbated problems; the JavaScript syntax looks so familiar to other C based languages that people feel that they don't need to learn it before using it. Lastly lets not forget that the DOM was one big shortcoming back in those days with an insecure and dubious API platform, upon which the entire web was built.

With all these problems developing for the web, especially with JavaScript, was a nightmare. jQuery came along and provided some much needed stability and consistency for a landscape that was terribly unreliable. The biggest features that jQuery brought to the forefront were:

Really though the first point encompasses the other three. In any case the impact that jQuery had on the state of the web cannot be understated. jQuery looked at the APIs that JavaScript and the DOM exposed and said "There's a better way to do this and here's how".

jQuery's contribution of selecting elements based on CSS selectors was absolutely revolutionary; accomplished by using the open source cssQuery to full effect. Back then the only other way to query the DOM was to use the not very fun getElementsByTagName() or getElementById(). Similarly, animations and AJAX requests went from unwieldy things to convenient and cross-browser consistent features.

Here's a SIMPLE example of a XMLHttpRequest from David Walsh's blog. Unwieldy to say the least:

// Just getting XHR is a mess!
if (window.XMLHttpRequest) { // Mozilla, Safari, ...
  request = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
  try {
    request = new ActiveXObject('Msxml2.XMLHTTP');
  } 
  catch (e) {
    try {
      request = new ActiveXObject('Microsoft.XMLHTTP');
    } 
    catch (e) {}
  }
}

// Open, send.
request.open('GET', 'https://davidwalsh.name/ajax-endpoint', true);
request.send(null);

The consistent and standard way that jQuery did things also made it very easy to learn, any programmer could pick it up and use it with very little need to check the documentation. jQuery had a certain "it just works" air about it, further solidifying itself as a first choice for web developers new and old. So why then, has it started to decline?

jQuery's Impact on the Web Landscape

It seems that jQuery has fallen to its own success. It has played its role so well that it has fundamentally changed the domain in which it operates. Here's some examples:

// Taken from https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
var element0 = document.querySelector(".myclass");
var element1 = document.querySelector("div.user-panel.main input[name='login']");
var element2 = document.querySelector("div.user-panel:not(.main) input[name='login']");

With all of these changes it looks like all of the fundamental value propositions that jQuery provides have been fulfilled and overshadowed by native solutions either by the browser or by upgrades to the DOM API. This explains the decrease in global usage, which then begs the question is jQuery still useful in 2022? - short answer is yes, longer answer is kind of.

When to Use jQuery in 2022

jQuery is still in use by a lot of websites, hundreds of thousands of websites in fact, so obviously it is still worth considering. The question then is where does using jQuery still make sense? In this I can think of two good use cases for jQuery:

The first use case for using jQuery is that it provides a comprehensive and consistent API for powering the front end of a website. Instead of having to learn all the various native APIs or special-purpose libraries, you can read just the jQuery documentation and immediately be productive, calling back to the "it just works" mentality.

This makes jQuery a great choice for new web developers but is a bit of a double edged sword. With jQuery on the decline and great frameworks like Svelte, Angular, React et al., its hard to recommend starting out with jQuery in good faith. Best case scenario they might have to use it to debug old code or add small functionality to a project that already uses jQuery.

The ease of use and learning curve cannot be overlooked though. Not only does jQuery superset the majority of the most common JavaScript tasks it is also quite easy to learn, given that jQuery uses an imperative approach. This imperative approach, however, does not scale particularly well with project complexity and codebase size.

This leads into the next use case of small web projects that need some, but not great amounts of interactivity. Not enough to use a more scaling declarative solution (like say React or Vue) but enough that writing your own JS solutions would be unfeasiable or introduce needless complexity. WordPress sites instantly come to mind here as an example.

Personally I think that the bigger the project, the less the need for jQuery is. jQuery, more so than declarative alternatives can quickly turn into a mess of tightly coupled components that produce enough side-effects to sink the project. I think Danny Guo said it well when he wrote:

If the project in question is expected to grow in complexity, it’s best to start with a different library or framework that will allow you to sanely deal with that complexity, such as by breaking the UI into components. Using jQuery for such a website can be fine at first, but it can quickly evolve into spaghetti code, where you aren’t sure what code affects what parts of the page.
I’ve dealt with this before, and the situation produces a feeling of uneasiness whenever you want to make a change. It’s hard to be sure that you aren’t breaking anything because jQuery selectors depend on HTML structure that is produced by the server.

In any case the iconic jQuery is not going anywhere any time soon, even if it is currently on the decline.