Since jQuery was released in early 2006, it’s become a staple in everyday web development. It’s used in over 60% of todays most visited websites, and without a doubt client-sides most notable and utilized library to-date.

jQuery became popular for one key reason: Its clean and easy to use API that abstracts the complexity of cross-browser scripting among even the most dated browsers. So as we approach an era of the Web where some of these browsers are quickly becoming a thing of the past, it’s understandable that we see a shift in the need for such APIs, and that the future of jQuery is in question.

But before you go cashing in your pesos, let’s consider the alternative.

Native API

While jQuery has added a tremendous amount of value to the web over the years, it has created a thick layer between developers and the DOM. Far too many developers don’t quite understand what is happening behind all those dollar signs. All while the majority of native equivalents are quite easy to use.

This doesn’t mean we need to void ourselves of jQuery. We must consider jQuery a tool, rather than a requirement. Evaluating the source of jQuery can provide a lot value and insight into what you are using. There has also been some talk comparing jQuery’s syntax to it’s native alternatives. These comparisons are a great basis for understanding what is happening behind the curtain, and a step in understanding the DOM. However, it’s important to also understand browsers are still prone to bugs. In fact, in the state of jQuery 2013 it is claimed that “jQuery 2.0 now has more patches and shims for Chrome, Safari, and Firefox than for Internet Explorer!”. Never the less, be careful when forgoing the use of a heavily tested, widely used library like jQuery.

You Might Not Need jQuery! … assuming you’ll address these bugs in your hand-written code: https://t.co/j2hrG2nCpX — Paul Irish (@paul_irish) February 7, 2014

The Syntax, The Abstraction

Server-side frameworks like Ruby on Rails, or client-side frameworks like Ember and Angular are widely used because we value convenience. Convenience equals time and time equals money.

jQuery === $ #amiright?

Each line of code written in these frameworks are evaluated by thousands of eyes. Mistakes are caught, bugs are found. There is strength in numbers.

We also value clean, proficient, fast, and slim code. Needless file size, unnecessary feature sets and conditionals are something we should be considering. Especially given the growing number of mobile visitors. This can be solved with modular dependency management.

“YOU MIGHT NOT NEED @jquery” Bullshit, we need granular dependency management for modular libraries. — Stephan Bönnemann (@boennemann) January 31, 2014

While the future of jQuery is uncertain, one thing is for sure, it’s not going anywhere anytime soon. And While jQuery’s source will continue to get smaller and legacy code will continue to be removed, we’ll still find ourselves using only a fraction of the library available to us. We shouldn’t need to include the entire library when all we need is a portion of it.

The future of jQuery is modular dependency management (hopefully).

Modular JavaScript

Browserify and RequireJS are two popular methods of writing modular JavaScript in the browser. Both of these tools have build scripts which only include modules that have been required within your application. If jQuery was modularized in this way, portions of jQuery that you don’t use won’t be compiled into your production code. You wouldn’t have to manually recompile your jQuery build every time you want to include a new feature. You’’d also never have to worry about removing jQuery features you no longer make use of. In development, these modules would be available to you, but wouldn’t live in production until they are required in your application.

As of jQuery 1.9, the source of jQuery has already been modularized. Short-term, this has enabled the use of a custom build-script to build your own jQuery. Many libraries have already implemented this type of building. Long term, however, this could allow for the use within an AMD-compliant loader.

Conclusion

jQuery is a powerful, well tested, highly utilized library available to JavaScript in the browser. While it may still make sense to include in most of your web applications, it’s important to understand the DOM isn’t such a scary place after all. jQuery can assist in extracting the bugs and complications within, but it shouldn’t replace the knowledge we have and our ability to navigate the DOM in a meaningful and effective way.

What do you think is the future of jQuery? Send me a message on twitter @davearel

UPDATE (February 27th, 2014):

If you’ve ever considered the implimentation of modular dependency management in a library with a monolith namespace like jQuery, you’ll understand that it’s not simple. Especially given the mass that is the jQuery source code. If you’re intrested in contributing to the discussion regarding the architecture of this, speak now: https://gist.github.com/davearel/9254418.