jQuery’s Relevancy – There and Back Again


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


  • Since jQuery doesn’t have a component model like React, Polymer, Angular, Ember etc., I wouldn’t recommend jQuery for building “non-trivial sites and applications”. Also jQuery encourages manual DOM manipulation which can quickly become a mess in terms of performance. Nevertheless, with jQuery it’s trivial to store your application state inside the DOM which can quickly become a nightmare in terms of maintainable code and unit testing. IMHO jQuery alone is much too low level to be considered a solid foundation for complex web apps.

    • Apologies here if you thought I meant that jQuery alone should be used literally for building out an entire solution. This is not my perspective or something I would assert. I think jQuery is good at abstracting the DOM. That is it. jQuery has more in common with lodash and underscore in this sense. One would not say that a Backbone application is built with underscore alone. Underscore is simply a lower level solution that helps one perform functional routines with speed and ease. This is very much the same role jQuery plays when scripting HTML.

      Also, I did not mean to setup a faulty comparison here. The manner in which you compare jQuery to React, Polymer, Angular, Ember etc. is a logical fallacy known as a faulty comparison. I’m not sure if you are asserting this yourself, or assumed I set it up. Either way, this is comparing two different things and claiming one is inferior because of the differences. jQuery was not created to be a solution for architecting an application. jQuery was created to make scripting HTML better. My claim is we should judge it on its intended purpose not its misuse or the fact it fixes bugs.

      • One could argue that architecting applications is all about building components. All these libraries / frameworks (React, Polymer, Angular, Ember etc.) provide a set of abstractions for building components, which unfortunately isn’t the case with jQuery. It’s easy to make mistakes when you have no constraints, especially when you code against the DOM. Nevertheless, jQuery did a great job in the past and paved the way for modern web development, however Web Components or React make jQuery quite redundant.

        • jQuery is not a view layer or a tool used to create componentized user interfaces. jQuery can help you do that, but jQuery itself is not that. jQuery = HTML scripting via JS. It is, what the DOM api’s should have been. You keep comparing jQuery to things like Web Components and React, these are in no way built for with the same purpose in mind. Using a tool that abstracts the DOM in a new way could result in not needing jQuery. But what is replacing jQuery is not react but rather the abstraction contained within react that handles a virtual DOM. This is the same for Angular and Polymer. These solutions did not get rid of the need that jQuery fills, they simply provided their own abstractions (e.g. Polymer.dom() and jqlite()). jQuery can become redundant, but currently is not irrlevant. Most of the solutions you mentioned are still offering a DOM abstraction of some flavor.

          • The comparison is actually in the context of the technologies that support writing software components, since they are the foundation of component-based software engineering. The implications are deeper than the Virtual DOM inside React, or IDOM inside Angular or Glimmer inside Ember. Let me give you an example: you can have a declarative API for your component, but this does not necessarily means that the internals of your component are written with declarative code – which is the case with many jQuery-based open-source and closed-source components. It’s really about how easy it is to read, understand and maintain a code base. As you can see, DOM abstractions alone are not sufficient to build real components and most of the time you’ll end up integrating clunky libraries providing abstractions that otherwise you’ll get out of the box inside libraries / frameworks like React, Angular, Polymer, Ember etc.

  • Pingback: Dew Dump – November 2, 2015 (#2124) | Morning Dew()

  • David Johnson

    Great article, agree with every word…well said that man

  • Great article Cody, well, I think the problem is that today, people is comparing jQuery (library) vs Angularjs (or another framework), and of course, the framework has a lot of things more than jQuery, but the purpose of jQuery is mainly work with the DOM, no be the base for the core application, also, jQuery can be use with any framework without problem!

    • I agree, a faults comparison is at work here. JQuery was not designed to be a solution alone for building complex sites or apps. Comparing it with solutions that were, is a flaw in reasoning.

  • thephilocoder

    I use jQuery along side Knockout and Angular, and it has been a great addition for problems that other frameworks cannot resolve well enough. So i think is good to know jQuery.

  • Great article. jQuery was built to manipulate the DOM and other JS frameworks build upon the DOM so I think it’s definitely here to stay for sure.

    • I agree. Vue.js, Ember, and Angular need something like jQuery if not jQuery. I’m so confused how people can recommend vue.js, ember, or angular and then suggest that jQuery is not needed. All these solutions use jQuery or use a jQuery like solution. Thus, it is relevant. I’d even assert that reacts virtual DOM is a form of DOM abstraction that validates the need to still abstract the DOM. But, to suggest that everyone should use react is rather short side as it assumes everyone is building the same thing.

  • Guess what React’s official tutorial uses for AJAX? Yup… jQuery.

  • Javi Gc

    I’m totally disagree, jquery was usefull when css3 and html5 didn’t exist, and existed a lot of browser incompatibilities.

    BTW jQuery(‘h2:eq(1)’) is not efficient not efficient, And if for you the main problem is the number of keys you press, there is a more better solution with vanilla javascript

    $$ = document.getElementsByTagName;
    $$(‘h2’)[1].style.display = ‘none’

    and to do the same I don’t need to download a library, and include it . Also you will write less, have more efficient code and won’t consume too much phone/table battery.

    • How is you “vanilla” code more efficient than jQuery(‘h2:eq(1)’).hide();?

      1) Your code is more work to write
      2) Your code is harder to read
      3) The $$ in your code only supports tag names
      4) Your code breaks when there is no H2
      5) Your code is more complex and therefore harder to maintain and debug
      6) If you want to hide every second H2 in every section, your code is much harder to change
      7) Your code is not more efficient. This is called premature optimization

      • Javi Gc

        1) avoid one call of 80k

        2) is harder to read if you don’t know how to develop, that is hard to you ($$(‘h2’)[1].style.display = ‘none’)?
        3) I know that jquery is to easy to use, but is too inefficient too, and most of developers doesn’t know how to use correctly jquery becouse it is too easy to use

        4) If a developer have to use a library becouse doesn’t want to use an if, maybe is not a good developer

        5) “$$(‘h2’)[1].style.display = ‘none’ “, is this too much complex

        6) Ii is a custom code, if my website doesn’t have a second h2, why I must execute this code in the first place? (and if the page is dynamic, maybe I would consider angular or embedjs)
        7) I have not applied any efficience, just a function to make the code easy to read, just as jquery

        I don’t say that jquery is a bad thing, 5 years ago, it was pretty useful, and helped a lot, an d I consider jquery that thanks to it, css3 and html5 are like they are now, but now that the problems of compatibilities are reduced drastically, there is no need to abuse of jquery anymore.

        You can create custom funcions that allows to have a “lite jquery”, and only use the methods that you really need

        • 1) It’s only 28k, probably a tiny fraction of the whole page. See https://mathiasbynens.be/demo/jquery-size

          2) $().() is so easy and powerful, custom code just can’t beat that.

          3) jQuery is sometimes not as efficient. Not in this case. Please read about premature optimization. It’s evil.

          4) If a developer uses a library so he is much more productive, makes code that’s easier to maintain and debug, then that’s a very good developer. Of course performance is important, but adding 28k to a page is almost always negligible.

          5) See 2)

          6) Because things change. All the time. jQuery is more robust.

          7) You said the jQuery code was not efficient. See 3)

          And you’re right, a ‘light jQuery’ can be the best solution. (by chance I’m working on one: https://github.com/edwinm/miq ).

    • If your preference is not to use the jQuery API because you think native DOM api’s are better I am not going to try and convince you other wise. Do what makes sense to your brain. However, objectively, the mass adoption by the developer community would leave your opinion in the minority. The majority of developers (not just advanced developers) found the API easier to work with. They can do more, faster, with it then without it. History seems to prove this true. My assertion is that it is still true based on the value of the API itself outside of updates to browsers or specifications.

      • Javi Gc

        I don’t think that is better or not, jquery have cooler selections that the native API. but is easy to avoid this extras on selectors that jquery brings.

        The main problem is too much easy, I saw a lot of web developers that never use variables, only use the “$” method, making the code too much slow to run, and only using the methods ‘ready’, ‘getElementByid’ and ‘getElementsByClassName’.

    • Alessandro Pellizzari

      What if you only have 1 h2 in your page? undefined everywhere! 😀

      • Javi Gc

        why I would call the function in the first place?

        • Alessandro Pellizzari

          You keep looking at the finger instead of the moon. What I am trying to say is that jQuery not only is shorter, but also safer, as you can reuse that function in every page without bothering to check how many h2 you have. Maybe the content was added via AJAX calls, maybe it was changed by the HTML guy. Your code is not enough to emulate the jQuery functionality, because you need at least a couple of ifs there.

  • Erwin Poeze

    Thanks for the article. Because constructing your own jQuery version might not be that obvious to everyone, we just launched http://www.jqueryconfig.com. It not only helps you pick the necessary modules, but offers insight in the effect that different modules have on its build size.

    • As far as I can see, this tool is creating a bundle that includes the desired modules. However, the bundle has no support for any module format (ES6 Modules / AMD / CommonJS etc.) and is exporting jQuery in a good old fashion global way. A more flexible option would be to have the sub-modules exposed as ES6 Modules / AMD / CommonJS etc. modules and allow the developer to bundle them programmatically. Also, in this way you would give the possibility to have jQuery either exported globally or exported as a module with no global leaks.

    • Thanks for sharing this. I like options. This is a nice option. With jQuery one can create a custom version of jQuery including only what they want. As the tool you have provided does. Or, they can use AMD and something like systemJS or webpack to include only what is needed.

      • Erwin Poeze

        I’m glad you like the tool, thanks. Yes, you are right that there are different ways to assemble the jQuery modules. We created jqueryconfig.com for the group of jQuery users that are not familiar with nodejs, webpack, etc.

  • Helder Cervantes

    jQuery is a pencil. It’s quite simple, really. You can write with it, you can draw with it. You can’t paint a building with it. There are better tools for that. Choose your tools wisely and don’t touch my pencils!

  • Mike

    I’ve been using jQuery for many years and it has given me back many hours of my life. Now days many folks are used to having new API/SDKs/abstractions appear daily, I wonder how many don’t likeuse it just because it is ‘old’ and ‘not the latest and greatest’. I’ll continue to use this finely worn and honed tool as it is reliable, understandable and gets the job done quickly.

  • HJ

    Totally agreed! jQuery makes life so much easier!

  • Avi Block

    The argument of which would you rather write, is a strawman. Most modern frameworks keep you away from the DOM, and with good reason. There is rarely any good reason to write jQuery(‘h2:eq(1)’).hide(); as your code will probably break next week when the designer decides to change the DOM around. Other reasons to stay away from the DOM are speed…a higher level abstraction like React, angular or vue.js will be able to do what you want to do, much more efficiently, and with much less (of your) code.

    • Which argument exactly is a strawman? I’m not exactly sure which sham assertion you are claiming I setup to then defeat. Additionally, I’m not directly trying to refute another argument. If you are referring to my general observation that some people think jQuery is irrelevant, well, isn’t that in fact the case? Don’t you think this? Or, you think I fabricated that?

      My claim is that the value of jQuery is connected to it’s API and that this value has not changed for those people who need to directly script HTML/DOM (be it app devs or lib devs). Thus it still has relevancy. I made no claim that people should use it instead of X,Y, and Z. You are actually claiming not to use it, and use X, Y, Z over it. Not everything that is done on the web is an application. At a lower level, jQuery is the ideal API to directly script the DOM. It was the purpose of its creation and is what gives it relevancy today for those that need a better solution that the native API’s.

      • Avi Block

        Your question was, what would you rather write, X or Y. Of course you would rather write Y then X therefore Z is a better solution. That’s assuming the problem at hand in modern client side development in 2015 was choosing between X and Y. That may have been the case in 2007, but is not the case in 2015. We’ve evolved, and no serious application will (or should) be doing jQuery(‘h2:eq(1)’).hide(); and certainly not the DOM api equivalent.

        Library and framework authors are not doing that either.

        If you want to claim that these frameworks are providing “jquery like” dom abstractions to their work, then that doesn’t prove the relevance of jQuery, which provide 300x more abstractions than are what these frameworks need to do.

        No series framework needs to do jQuery(‘h2:eq(1)’).hide();

        • I think the demonstration I gave might be in our way here. My point, let’s set aside the specific code example, was that the value of jQuery is tied up in the API. The fact that it makes any and all DOM scripting easier and faster is where the value lies. My claim is that this value is still relevant today. For example things like Ember (i.e. authors of solutions) and for developers (i.e. not everyone is building an app). jQuery is not needed, it is desired. Just like I don’t need lodash to do functional programming but I desire to use it when I do it. When I need to script the DOM I don’t need jQuery I desire it because of what it can do for me. This translates to a range of contexts that developers find themselves in, not just application development.

          • Your code example may be bad practice when used against but it doesn’t mean it’s irrelevant. Avi Block think of a good use case for what he has said if I have made a plugin that injects a particular set of nodes in the DOM which will always be structured the same way as long as the plugin is used then there can be a case of $(‘.pluginSelector:eq(1)’).hide(); . There’s no point in bashing a solid point that has been made. I don’t use jQuery on my personal website because I have very trivial need for JS and my few DOM manipulations shouldn’t require that I affect my performance with the entire library but when it’s a non-trivial application and there’s obviously a need for jQuery then I’ll go for it. What makes good developers is the ability to get the right tools for the context and use them properly rather than embrace certain methods just to feel cool or be among the majority that use them.

  • opus131

    jQuery was a blessing when it came out; and I will always be grateful to John Resig and hold him in the highest regards for giving it to the community.

    However, in 2015 is only useful in the following ways:

    * For identifying which libs and products *not* to use, because they still require it.

    * For identifying which developers *not* to hire because they have not moved on and still rely on it, while much better alternatives exist for all the use-cases jQuery covers.

    • Every angular developer that uses it or jqlite should not be using it and should not be hired?

      • opus131

        What an unfortunate choice to bring up angular – unless you are trying to help me make my point: when it came out in 2009, embracing jquery/jqlite was a valid design decision. In 2015 it is not, and of course the angular core team is aware of that – which is why there won’t be any jqlite or jquery in Angular2.

        And yes – when I have the choice between two frontend-dev candidates who are otherwise equally skilled, I’ll hire the one who understands that jquery no longer has a place in the frontend-dev toolchain in 2015, and that it is not a good choice for a new project.

        ps: Not nice how you were trying to twist my words – I never suggested not to hire angular devs – I like angular a lot…

        • I asked you a question. I didn’t assert anything. Not sure what you think I twisted when I ask only one question. I was asking for clarification. Suggesting that because Angular 2 does not use jQuery, therefore no one should use does not follow. I’m unclear why you are being so dogmatic about a tool that still helps devs get the job done today. I’m not asserting that it should always be used. However, you are asserting it should never be used. And that you would not hire anyone who uses it today. The first assertion is an objective claim, while the second is rather subjective. Please tell me why you think objectively no should be using jQuery today. I’m open to being wrong if you have a rational argument for such a bold claim. However, just asserting that it is true does not make it true.

          • opus131

            >> Suggesting that because Angular 2 does not use jQuery,
            >> therefore no one should use does not follow.

            Wow, you are twisting my words yet again. Did I suggest that no one should use jquery because Angular 2 does not use it? I didn’t even mention Angular in my initial comment – you brought it up in your reply.

            Anyhow, don’t bother replying, I do not have time for sophistry, I’m out of here…

          • I didn’t twist anything the first time. I asked a question. If my question or statements do not follow from your assertions then you simply need to make a clarification. I can’t perfectly understand your perspective without asking questions or trying to figure out what exactly you are saying and why.

            I am open to thinking about your claims if you could support them with reasons. Simply stating something does not make it obviously the case. You seem to think jQuery should not be used and go as far to say a developer should not be hired if they use it. You need to justify that rationality before I just accept it.

    • CodeMonkey432

      Twisted your words? No, he simply showed the fallacy of your attitude and you had no reply. Man… coders like you…I would never TAKE a job from you with your attitude. You must be a joy to work with – nice rage quit.

  • Madara Uchiha

    You aren’t really being fair with your examples here.

    `document.querySelector(‘h2:eq(1)’).hidden = true`

    Which is supported by anything that supports querySelector. so it’s really a case of whether you need IE8 or not.

    If you need IE8, you definitely want jQuery to iron out the quirks. But if you don’t, the quirks today aren’t really about the DOM, more of the actual ECMAScript implementation, and jQuery doesn’t really help you there.

    • If one must script the DOM in 2015 in a non-trivial fashion are you suggesting that the native DOM API’s do a better job (ease of use, speed to get something done, semantical readable api..etc…) than jQuery? The DOM did not all of a sudden get better because it offers a few of the patterns jQuery made popular.

    • steve

      Native js even with querySelectorAll isnt as elegant or as flexible as traversing sideways with siblings, downwards with children, or upwards with closest parent of the found elements. Multiple binding or delegation is clunky without it. Killing a bind event or resorting thr event order. Jquery isnt just a prime element selector engine. It is terse, compact, easier to read and much more flexible. The only reason developers are dismissing its worth now is due to the abuse of dependencies on elements existing in the dom. Once you change the html, you break the js chain. Thats why data binding evolved to make clear in thr html what the dependencies are. Unfortunately they dictate the formula of javascript structure and its not to everyones taste. Jquery is popular still because it is to most developers taste. The learning curve is tiny. So thats why, despite the abuse and poor architectural decisions made by previous cowboys, it is much easier to read, fix, restore any btml chains even if they do break.

  • Pingback: Web Development Reading List #111: Preconnect, Dynamic Responsive Images, DOM Event Listeners - American Fido()

  • Agreed. Why use a task manager (grunt/gulp)? Because it’s efficient to handle the repetitious tasks that we hate doing. Why use jQuery? Because it’s efficient to handle the repetitious tasks that we hate doing.

  • Ben

    jQuery is nice if you don’t have any of your presentation tied to data, as most serious applications do. Frameworks like Ember manipulate the DOM based on the state of data and properties, which keeps the developer safe from manually updating certain UI elements when data changes, but forgetting others. If you’re using a framework, introducing jQuery doesn’t do much more than introduce the risk of inconsistency and a UI that don’t property reflect the data backing it.

    • Ember uses jQuery, today, right?

      • Ben

        Yes, but that’s all handled internally. If I find a situation where I want to use jQuery directly in an Ember app, 99% of the time I’m taking the wrong approach.

        • Sure. My point in the article is that its mere usage by either dev (hopefully correct) or *libs* still makes it relevant. I’m not claiming more or less.

          • Ben

            Yes, I agree.

  • Stephen Tang

    Thanks for writing this, Cody. I think the majority of the audience that reads this are web application developers/full-stack, who are accustomed to using React/Angular/Ember, etc. frameworks to write complicated web applications. This audience biases the resulting comments. But, simpler projects involving the DOM without much data-binding and Ajax stuff still exist!

    There are many developers/designers working out there that are not involved in the web app/SPA development, and jQuery is still very helpful here. The “advanced” and “rock star” developers can continue to argue which framework is great, but the rest of us are just trying to get the job done.

    • Well said. I can’t help but even feel a tingle of elitism going on here in other comments. This is why the bases of my argument is for scripting HTML in non-trivial situations. I made no claim that jQuery should be used when building applications. However, again, today, Ember, Angular, vue.js, Meteor and others all make use of the jQuery API either directly or by mimicking the API. To conclude absolutely that jQuery is not relevant today is logically false. It does not follow from the evidence. It is still very much a needed abstraction. Much like underscore or lodash.

  • Cris Moreno

    In fact, jQuery helps us develop applications leaving the part of the administration of the DOM, besides being a well tested and maintained by large developers library, which gives us the space to focus on the application, in addition to help us write clean code and good practices using Javascript, and for those who are beginning to understand the jQuery code is too learned, and also for those new to the world of JavaScript, jQuery helps them begin to develop real applications.

  • The problem with jQuery was that it was all tightly coupled, and all namespaced under the $. There was no way to load just the one piece of jQuery you want to use, without loading all of it. If all you want to do is call that .hide() method you mentioned, you shouldn’t have to load all the other stuff jQuery does. Maybe that’s better now, I’m not sure.

  • rbrtsmith84

    Hit the nail on the head. Abstractions in all forms of programming are necessary, what’s important is that you understand what lies beneath the abstraction, then you can make an informed decision if, when or how to use it.
    jQuery abstracts over probably (According to Doug Crockford) the worst API ever conceived. One mistake many mid-level developers make is they try to overcomplicate things, sometimes to make themselves look superior. On a large project the last thing you want is technical debt, which is what you get when trying to do anything beyond trivial interactions with the DOM .

  • Nope

  • Pingback: JS - pplanete | Pearltrees()

  • I am not against using jquery for DOM manipulation, but I generally recommend a declerative approach with data binding instead. The biggest problem with jquery is the tight relationship between DOM and code since it assumes a fixed DOM structure. This makes the code fragile since the slightest change in the markup might cause your code to fail. It’s also hard to unit test because of the hard dependency on the DOM.

    I have a few more thoughts here: http://www.syntaxsuccess.com/viewarticle/is-jquery-still-relevant

  • Dale Anderson

    The problem with jQuery as it stands is its bloat. It contains implementations for features that overlap with other, potentially “better” implementations. Promises is a good example – the jQuery implementation is not standards compliant and causes headaches when interacting with other promise libraries.

    With modern browser UI frameworks that support data binding, or virtual DOM diffing, or whatever, direct DOM manipulation is generally not required. jQuery IS irrelevant, except for smaller projects.

  • Alex Kloss

    The primary example only fails in IE because you used .setProperty. Had you used `document.getElementsByTagName(‘h2′)[1].style.display=’none’;`, it would even have worked in IE6.

    Yes, you can speed up development. You can also slow down page performance (I know, that’s mostly negligible, but faster is always better). What I want to say is: know when and when not to use it.

  • Pingback: jQuery’s Relevancy | David A. Kennedy()

  • Pingback: JS - pplanete | Pearltrees()

  • Pingback: Link Round Up #5 » Blog » Snow Tips()

  • Mike Cavaliere

    I love this article – very relevant topic and important point. We’re in an age of Javascript frameworks & libraries, and there are a fair amount of them.

    It’s easy to jump on the bandwagon of “what’s the hot new tech” and always ride that wave. But while Angular or React or the others are phenomenal, for some projects they’re complete overkill.

    And while Javascript itself is evolving and some people like using vanilla JS to lean things up, you can still save a ton of time and hassle on a great many projects using jQuery. Technology is best when using the appropriate tool for the job at hand whenever possible.

  • Pingback: What To Expect From JavaScript In 2016 - Frameworks - Telerik Developer NetworkTelerik Developer Network()

  • Edwin Reynoso

    Hey Cody I’m wondering what you think about NodeList.js (https://github.com/eorroe/NodeList.js)

    To quickly compare your example:


    NodeList.js Which makes using the native DOM like jQuery:

    $$('h2').item(1).style.set('display', 'none');