The 4 Reasons Why We Stopped Using jQuery
15
minute read time
A Once-Essential System
The time has finally come. Just five years after we published our blog 6 Reasons Why We Still Use jQuery, the Atypic development team has officially ceased using jQuery on any new website going forward.
While it’s been well over a decade since jQuery could be considered cutting edge (and that is being quite generous), it still quietly commands an enormous presence on the internet. According to metrics from wctechs.com, in 2024 jQuery was still being used by a whopping 72.6% of all websites, giving it JavaScript library market share of 89.7%.
Developers that have primarily worked on single page applications (SPAs) for the last decade, or fresh graduates that have come of age in the era of React, might be quite shocked to learn that statistic. The key to understanding why jQuery is still so ubiquitous is understanding its primary use case: jQuery still remains a perfectly adequate (and easy to learn) library for sprinkling a bit of interactivity and animation into fairly simple and static websites.
So what’s changed for us?
To put it simply, the benefits no longer outweigh the significant drawbacks we continue to encounter in supporting it. If you’d rather us put it less simply, here is a list of reasons why we no longer use jQuery at Atypic.
01. Limited Usefulness
When ECMAScript 6 was introduced (also known as ES6 or ECMAScript 2015) it negated the need for many of the functions that jQuery provided to tame the wild cross-browser differences in Javascript during its heyday (99% of which were only issues because of the now fully defunct Internet Explorer).
jQuery Functions and Their Modern Equivalents
The code footprint and readability of plain old Javascript is now largely on par with jQuery. Rewriting an existing code base to account for the many small differences in syntax may be a bit of pain (trust us, we just went through it…), but once complete, you will barely notice a difference in your day-to-day programming. jQuery just doesn’t improve developer experience by a significant margin anymore.
02. Outdated/Unsupported Libraries
One of the primary time-saving upsides of jQuery was the existence of numerous free and open source jQuery libraries & plugins; today many of these are no longer actively maintained. In some cases, that may mean they’re filled with scores of unfixed bugs, and in other cases can have sluggish performance due to outdated/unoptimized code. In the worst cases, they just won’t work at all any more. The unfixed bugs in the Slick Carousel library were what finally led us at Atypic to create our own carousel code in plain Javascript, and begin the transition away from jQuery in earnest.
03. Versioning Conflicts
As developers working within an agency environment, we are responsible for producing code for a wide range of platforms. While we may be able to control which jQuery version runs on websites built fully in-house, when producing code for our client’s existing websites, we are generally building on top of an existing Javascript environment, and that environment may have a specific (and outdated) jQuery version requirement. Most often this is because a site’s functionality is reliant on a Wordpress or Drupal plugin that was originally developed long ago with an older version of jQuery; in these situations we sometimes have to adjust / rewrite parts of our jQuery scripts, and sometimes we even have to remove and replace entire jQuery libraries due to these conflicts.
04. Better Alternatives
This may be old news to most developers that have been keeping up with trends in front-end development, but in the past decade, there has been an explosion of amazing alternatives to the heavily DOM based functionality jQuery provides. Here at Atypic, we use the following technologies in tandem, as they are fundamentally very compatible to use alongside one another:
Alternative A - Plain Javascript (via Web Components)
Web Component technology allows us to write fully encapsulated Javascript, and attach it to custom HTML elements that we define. For the everyday Javascript we write at Atypic, this is the approach that makes the most sense as a jQuery replacement. The code we are able to write is modular, easy to update, and best of all, much more performant than our previous jQuery implementations.
Alternative B - AlpineJS
AlpineJS is a very lightweight library that can inject reactivity into websites with the syntax of an SPA, but without the drawbacks, such as a compile step or SEO unfriendliness. Alpine has proved invaluable to us for creating advanced components on websites that need to frequently and efficiently update the elements on the page as you interact with them (mortgage calculators, product search filters, advanced search forms, etc.) As someone who has decades of experience duct-taping these kinds of components together using jQuery, trust me, there is nothing in the jQuery ecosystem that is even a close comparison.
Alternative C - VueJS (Or Your SPA of choice)
For entire SPAs, or advanced “app-like” components that exceed a certain threshold of complexity, VueJS is our go-to. This blog is not about comparing SPA technology (i.e. React, Vue, Angular, Svelte, etc.), as these can all be used effectively to accomplish the same goals, but Vue and AlpineJS share a very similar syntax that allows us to very easily convert an alpine script into Vue if we determine that we need to switch our approach (or vice-versa.) As a bonus, it pairs very well with our Laravel based backends!In Conclusion
After over a decade of writing the bulk of our front-end Javascript in jQuery, our team has officially moved on. What was once an essential library now is more of a hindrance than a help. In 10 years, let’s hope the aforementioned alternatives don’t meet the same fate!
