Telerik blogs

Because of the mounting you-don't-need-jQuery sentiment as of late, I can't help but think we have forgotten the basic value of jQuery. So I think it is time to remember.

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.

What Is JQuery?

jQuery is a JavaScript library (i.e. written in JavaScript) designed to abstract, equalize, fix, and simplify the scripting of HTML element nodes in a browser or headless browser.

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 querySelectorAll() or setProperty(). So, while the previous jQuery code would run just fine in IE8, the native DOM code would cause a JavaScript error. But consider, even if both lines of code worked everywhere, which is easier to write and read?

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.

Is jQuery JavaScript Itself?

Because of jQuery's ubiquity, depending upon your background, you might not know where JavaScript ends and jQuery begins. For a lot of designers and new HTML/CSS developers, jQuery is their first interaction with the JavaScript programming language. Thus, they sometimes confuse jQuery and JavaScript itself.

First off, you need to know that JavaScript is not jQuery or even the DOM API. jQuery is a third-party open source library maintained by developers in the web community and written in JavaScript. Also, jQuery is not a standard from the same organizations (i.e. the W3C) who produce the HTML, CSS, or DOM specifications.

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.

So many developers use jQuery and jQuery Plugins that you will often find them being touted as the most used scripts on the entire web.

The Two Conceptual Pillars Behind jQuery

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 note that jQuery does do a little bit more than what I just stated. In addition to abstracting native DOM interactions, jQuery provides an abstraction for making asynchronous HTTP requests (aka AJAX) using the XMLHttpRequest object. It also provides a couple of other smaller JavaScript utility solutions and miscellaneous tools but the main use case for jQuery resides in the fact that it makes scripting HTML easier, faster, and more enjoyable.

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.

How jQuery fits into modern web development today

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.

Even if you feel that jQuery objectively helps, this preference does not make jQuery irrelevant. It is as relevant as anything that a group of developers prefer, like CoffeeScript or TypeScript. You don't need these to write JavaScript, some developers just prefer it. In the same way, we don't need jQuery to script HTML, but it just so happens that a hell of a lot of developers prefer it. This alone makes it 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.

Appendix - Important Facts About jQuery

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.

  • jQuery was created by John Resig and released on August 26, 2006. According to John the reason he wrote the code was to "revolutionize the way you can get JavaScript to interact with HTML".
  • jQuery is considered to be the most popular and most used JavaScript library to date.
  • jQuery is free and open source software provided under the MIT license.
  • jQuery comes in two versions. The 1.x version (current: 1.11.3) which supports Internet Explorer 6, 7, and 8\ and the 2.x (current: 2.1.4) version, which drops support for anything less than IE9+ . If you need to support IE8, then you'll have to use the 1.x version. But that is ok, both versions are still being actively developed.
  • jQuery 2.x minified is around 82kb. Gzipped it's around 28k.
  • jQuery 1.x minified is around 96kb. Gzipped it's around 32k.
  • jQuery source code is available on Githhub.
  • Using the source from Github a custom version of jQuery can be constructed.
  • jQuery can be installed using the bower or npm package manager (i.e. $ bower install jquery or npm install jquery).
  • jQuery has an official CDN serving many versions of jQuery.
  • jQuery has a simple plugin architecture that allows anyone to add custom jQuery methods.
  • The jQuery plugin community is vast. High quality enterprise grade plugins (e.g. Kendo UI) for purchase are available as well as many high quality free plugins (e.g. Bootstrap).
  • jQuery can be broken down into the follow categories (matching how the API docs are broken down).
    • ajax
    • attributes
    • callbacks object
    • core
    • CSS
    • data
    • deferred object
    • dimensions
    • effects
    • events
    • forms
    • internals
    • manipulation
    • miscellaneous
    • offset
    • properties
    • selectors
    • traversing
    • utilities
  • Anyone can contribute to the jQuery project.

Header image courtesy of Jeff Hitchcock

About the Author

Cody Lindley

Cody Lindley is a front-end developer working as a developer advocate for Telerik focused on the Kendo UI tools. He lives in Boise, ID with his wife and three children. You can read more about Cody on his site or follow him on Twitter at @codylindley.


Comments are disabled in preview mode.