In this article, I’m going to remind everyone what exactly jQuery is, because I believe that jQuery is as relevant today as it was when it was first written. The question relevancy should be tied to the original intent of the solution (i.e. the jQuery API itself) and not browser bugs or missing features. If we suggest otherwise, we run the risk of fueling a perspective that could be used to dismiss any abstraction that is not required, but none the less still powerful and helpful.
Before I get too far into defending jQuery’s relevancy, let’s first journey from the beginning again and back so that everyone is clear on the “what” and “why” of jQuery.
To be clear:
Wrap all of this up into a simpler, less buggy, API than the native DOM API provides and you have jQuery.
Now let me explain what I mean by “scripting HTML elements”. Using jQuery it becomes trivial to do stuff like visually hiding the second
<h2> HTML element in an
.html document. The jQuery code that would accomplish such a task would look like so:
Let’s break this line of jQuery code down a bit. First, the
jQuery() function is invoked, passing it a custom jQuery CSS selector which selects the second
<h2> in an HTML document. Then, the jQuery
.hide() method is called which results in the
<h2> element being hidden. That was simple and semantically clean to express using jQuery.
Now contrast this to the native DOM code that would be required if one didn’t use jQuery.
Which would you prefer to write? Or read and debug? Also, consider that the native DOM code above assumes that all browsers support the DOM methods used. And as it turns out, certain older browsers don’t support
By employing jQuery you don’t have to worry about which browser supports what, or which DOM API might bug out in which browser. Using jQuery you are able to get things done more quickly with simpler code and less stress because jQuery abstracts these issues away so you don’t have to worry about them.
Keep in mind that jQuery primarily serves as sugar over the top of the DOM API. This sugar helps to conceal what has historically been a complicated and buggy DOM interface.
jQuery is simply a helpful library that you can optionally use when scripting HTML elements. And the fact is, most developers choose to use it when scripting the DOM because the API helps them get more things done with less code.
The two basic concepts behind jQuery are: “find something, do something” and “write less, do more.”
These two concepts can be expounded and combined into the following statement: jQuery’s first order of business is to orchestrate the selection (i.e. find something) or creation of HTML elements for the purpose of doing something with them that, without jQuery, would require more code and more DOM know-how. For instance, the hiding of the
<h2> element we spoke about earlier.
It’s important to point out that I am not suggesting that its value resides in its ability to solve browser bugs. The conceptual pillars don’t even hint at the value of jQuery being rooted in browser fixes. jQuery’s value long term is tied up in the simplicity and power of its API abstraction over the DOM. And this has always been its value.
jQuery is almost a decade old. Crafted for a period of web development that we have most certainly surpassed. The fact is, just like 10 years ago, jQuery is not absolutely needed to work with the DOM or make an asynchronous HTTP request. Most everything you can do with jQuery you can do without jQuery. And, if you require only a couple small simple interactions with the DOM in one or two modern browsers, then you might be better off using native DOM methods instead of jQuery.
However, for any development that involves the BOM (Browser Object Model) or DOM beyond a trivial sprinkling of interactions, you should make use of jQuery. The alternative would be to reinvent the wheel (i.e. parts of the jQuery abstraction) and then test that wheel on every major surface (i.e device and desktop browsers) on which the wheel might turn.
Mature developers know when to stand on the shoulders of giants and when to avoid unnecessary complexity. In most cases, we still need jQuery to get things done in a reasonable amount of time when doing non-trivial work with HTML and the DOM.
Besides, even if jQuery didn’t fix a single issue with the DOM or the browsers’ disparaging implementations of the DOM specification, the API itself would still remain relevant due to its ease of use for scripting HTML.
jQuery is still relevant today not because of fixing something that is broken, but because the abstraction improves upon the underlining DOM APIs.
And these improvements help developers work smarter and faster. This is as true today and it was when the library was first crafted. Saying you don’t need jQuery today is like saying you don’t need lo-dash or underscore.js. Of course you don’t need any of these things. But needing something is not the only manner in which value is measured.
The value of these things is in the API. Complexity can slow you down during development. For this reason, we prefer using things like lo-dash and jQuery to make things simpler. They help us do difficult things with ease. And as long as jQuery helps us to do difficult things with ease (i.e. scripting HTML), it will remain relevant.
If you still have concerns about the use of jQuery in modern development today, I suggest watching the following presentation from a jQuery team member where he makes the case for continued use of jQuery regardless of the advancements of modern web browser.
Now, if you have decided not to use jQuery for the development of non-trivial sites or applications, I’d like to hear why. Tell me in the comments.
As a final item, I’d like to share some important facts about jQuery. Some of these you may not know or perhaps have forgotten as we move farther from jQuery’s original creation.
$ bower install jquery or npm install jquery).
Header image courtesy of Jeff Hitchcock