DEV Community

Cover image for Long Live jQuery
Ben Halpern
Ben Halpern

Posted on

Long Live jQuery

The reports of jQuery's death are greatly exaggerated.

jQuery, which recently announced its first 3.0 release candidate, has been an important tool for web development since its inception. The library provides a rock solid API for interacting with the DOM and other critical browser functions while hiding ugly syntax and awful browser quirks. For all that the ubiquitous library has offered the web, it still gets a bad reputation. It seems to me that people have been calling for its demise for some time, to be replaced with "modern" paradigms like React or Ember or Vue or Angular or your own crappy framework. These frameworks are great, but I believe they do not "replace" jQuery at all. They compliment jQuery and have fundamentally different use cases.

The popular modern frameworks were built to handle complex client-side data and state. They provide important solutions to problems that were, frankly, brutal to deal with before they came along. But they bring with them their own inherent complexity and a lot of baggage in the form of file size, framework lock in, and mountains of their own complexity. jQuery remains a brilliantly intuitive API for dealing with basic client-side interactions. I believe that when developers avoid chasing shiny UX pattrens, they can provide a pretty damned good experience without even taking on the need to handle all the complexity of state on the client in the first place. There are many different ways to architect complexity into an application and, frankly, it does not have to surface on the client as is the popular style today.

I have personally taken on the approach of using React.js on projects that have an obvious need for its patterns and avoiding opinionated, build tool reliant libraries and frameworks like the plague if their need is not clear. This approach has worked out for me and helped me avoid the dreaded JavaScript fatigue you've heard so much about. While it's nice to return to nature and write plain old JavaScript, in practical senses, jQuery is the technology of choice as the backbone for basic development projects that have a web front-end.

At some point, jQuery earned a reputation as a crutch for developers who never really learned JavaScript. There is some validity to the criticism of anything that can be deemed a crutch, but don't hate the player, hate the game. This reputation really speaks to the API's ease of use, and like any dev tool with such a with a low barrier to entry, there is going to be a lot of brutal code written with it.

jQuery is still the tool of choice for adding an interactive layer to a website that does not require maintaining a complex global state. According to BuiltWith, 77.9% of the top one million websites use jQuery. Literally anyone you bring onto the project will either know jQuery already or have a really easy time picking it up. It is so popular that, when I using vanilla JavaScript, I find myself needing to append "without jQuery" to search queries when I am looking up JavaScript web solutions on Stack Overflow. While it is a crutch for some, it tends to beat writing vanilla JavaScript in terms of actually getting stuff done quickly, and weighing in at 28kb Gzipped, it is a relatively affordable choice in terms of bandwidth.

As with any tool, jQuery is best used with discipline and purpose. If you can architect an application in such a way that the complexity does not rise too close to the surface, jQuery is the perfectly reasonable choice. Its temultuous reputation is based on the ways it has been abused, not based on its API or anything that has fundamentally changed in web development. With the release of 3.0, which builds on the mature API with enhanced promise support and performance boosts under the hood, jQuery is here to stay as the reasonable choice for most of the functionality web developers need.

Top comments (1)

Collapse
 
yo profile image
Yogi

But GitHub Ditched it - githubengineering.com/removing-jqu...