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.
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).
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.
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.