What’s the future of jQuery in 2018?

Hi – so I just wanted to take an opportunity to enquire about the future of this library and what the plans are going forward in terms of updates and support.

Over the last few years it’s fair to say the landscape has changed, frameworks including Angular, React and VueJS have introduced a new paradigm for writing JavaScript and in some ways made jQuery redundant – to the effect that it’s encouraged not to load/use the library at all.

This is also inline with an observable decrease in the number of releases being pushed, with just 3.2 and 3.2.1 this March. Before that, 3.1 shipped in July 2016. And whereas there were 8 blog posts in 2015 and 16, there has just been the one this year, and ever since, silence.

During this time, we’ve seen a number of major changes in the JavaScript ecosystem, including (and not an exhaustive list): promises, arrow functions, spread operator, async/await, generators, fetch api (replaces ajax), template literals, let/const and classes.

All of these changes can add up to one of the biggest rewrites of the library we’ve seen to date. I question whether Ajax is still required now that Fetch is supported on all major browsers.

With all that said, my main question is what is the plan going into 2018 and beyond in regards to jQuery; it’s no lie with each passing year an already aging codebase, some of which hasn’t been touched in years, continues to be common across the web. It’d be delightful to see a v4 project attempted to try and remove any parts which are no longer required and focusing on keeping only the absolute essentials, focusing on extreme performance and a modern codebase now that all these new language features have been added to the browser.

Thank you and I look forward to any comments this issue may generate.

Happy coding 🙂

Author: Fantashit

7 thoughts on “What’s the future of jQuery in 2018?

  1. First of all, thank you for your question.

    Let me start by pointing out that the team decided a while ago to release at a slow but steady pace, which we translated to about 2 releases a year (3.3 is coming soon). We noted that when we bombard users with releases (especially when there are breaking changes in those releases, intentional or otherwise), we added to the workload of our users in recommending that they upgrade. Each release has the potential to affect not only users’ websites, but the entire plugin ecosystem. Also, we are all volunteers with demanding jobs and don’t work on jQuery every week.

    In regards to features, you are right to note that jQuery is not a framework. I describe it as an elegant, lower-level API to make working with the DOM easy across browsers. jQuery can and does get used alongside robust application-building solutions like Angular and React/Redux, but it’s main usage probably still lies within more websites rather than web applications, if I can make that distinction. As you noted, we generally pay more attention to what we can remove rather than what features we can add. For more info on that, our guidelines for adding new features are laid out here: https://github.com/jquery/jquery/wiki/Adding-new-features.

    All that said, while we plan to release jQuery 3.3 and subsequent patch releases very soon – and there are some minor features being added in that version – we have bigger plans for jQuery 4.0 and upcoming major releases.

    This includes:

    • A complete rewrite using next generation JavaScript. This in turn requires an update to our build system, because we want to use es2015 modules. We need to do this in a way that keeps the final size identical or smaller than the original.
    • A rewrite of our speed framework, to keep track of performance regressions in common operations.
    • An all-new event module design, which is detailed here: https://github.com/jquery/jquery/wiki/jQuery-4.0-Event-Design. If we can get it done, this new design will allow us to support new native options like passive event listeners. Right now, jQuery adds one handler per event type and takes care of when to call the user’s handlers manually. This was the only way to do it when we supported old IE, but it’s becoming more plausible to add a native handler for every user handler and let the browser do more of the work.

    We keep track of these larger plans and more on our Roadmap.

    Again, thanks for your question. I’ll go ahead and close this since it is not a bug or feature request, but feel free to continue discussion.

  2. The projects you mentioned have a much larger scope than jQuery Core and aren’t really worth comparing to, and while there is certainly a drop in number of commits, I believe we still have a strong, competent team and a fairly active community through irc and gitter. And while Angular, React, and similar projects have gained wide usage in the US, the story is not quite the same worldwide. In other words, I think there’s definitely truth to what you’re saying, but jQuery isn’t going anywhere for a long while.

  3. jQuery is still used by the vast majority of web sites (as opposed to web apps), including 90%% of the top million sites by traffic according to BuiltWith. Many web apps are not part of the crawlable web that BuiltWith monitors, and that’s what many of the big frameworks are focusing on.

    What is jQuery not doing that people think it should do? The majority of feedback we get is about changes that are not compatible with previous versions, regardless of whether the previous behavior was documented or not. That is a long way of saying that people aren’t that fond of changes.

    I think it’s a mistake for someone building an Angular, Vue, etc. to use DOM manipulation with jQuery because the most common use is to pull in DOM-stateful plugins that defeat the very reason for using those frameworks in the first place. Those communities should be building widgets that work properly with the framework instead.

  4. While progress is a great thing and I’m thankful for the plethora of frameworks to chose from for building web sites and apps, I doubt jQuery will be going away anytime soon and there’s no reason it should, any more than reason for C or SQLite to be going away because they’re old. Hype will always exist for the current shiny new thing – sometimes justified, sometimes not, but for me there’s no substitute for the confidence of knowing you’re using a seasoned, stable, thoroughly tested, well documented library with a huge install base, knowledge base and plugin ecosystem. As usual, it’s always a question of choosing the right tool for the job, but my point is that there are still many jobs for which jQuery is still the right tool, and will probably continue to be.

  5. There are many things jQuery made much easier back before ES2015 (ES6). To me this isn’t about framesworks and jQuery isn’t a framework so to compare it to Angular (which is dying), React and Vue is silly. Angular 1.x had jqLite built in and most projects I worked on we added jQuery. But since React, and now newer versions of angular, how we work with the DOM is completely different. It used to be super handy to use jQuery selectors, but we rarely have to use selectors anymore and when we do need to use them, they are just as easy to do with standard ES2015 JavaScript.

    AJAX used to be another popular area jQuery came in handy and the same with promises. But now the newer versions of JavaScript have a nice clean and easy way to do AJAX calls and the promises are built in using fetch. Promises are now in newer JavaScript versions so no more need to use jQuery for them.

    Babel is also very popular, as is TypeScript, and both of them allow us to be cross browser compatible, which was something jQuery really used to help with.

    Seeing these comparisons with frameworks makes me wonder how informed some of you are about JavaScript in general. Comparing jQuery to React is like comparing comparing a bicycle to a sports car.

    So the issue with why jQuery is dropping off, and will continue to drop off, in popularity is simply because JavaScript has gotten a lot easier to work with. Frameworks might also be a reason why jQuery isn’t used much simply because the frameworks have a lot of built in functionality and combined with newer versions of JavaScript I have yet to see a benefit to using jQuery.

  6. Woah! Hold yoar hoarses bruvas! 😉 jQuery rawks like nun other! Ok, enough with the alphabet riddles 😉 What I mean is, jQuery is still currently highly relevant for me as far as building customized kickass SPAs that function like stand-alone software (not web pages). I’ve been on the jQuery cloud of joy for the last 4 years now and the only reason for doing so is to be able to code less, and design more.

    I’ve dealt with javascript in the good ‘ol days of Netscape / IE wars (some grey hair here lol) long time ago. In those times you would design applications with Flash (ActionScript) and DHTML (remember those?). Web pages back then were becoming more dynamic, and less boring. But, besides the orgasmic headaches of cross-browser compatibility lol, the code base was long…. wayyyy tooo lengthhhhyyyy. Then, much much later. surpriiiise…. jQuery arrives. It’s goal: To boldly go where no other coder has gone before! Talk about success! jQuery, among other awesome things, introduces less code for more normalization, so… BINGO: You have a javascript library that removed the headaches of cross-browser compatibility.

    The relevancy of jQuery today equals the facility in designing through code. A major reason I adopt jQuery is to stay closest to native code without the constraints of frameworks (I emphasize). That allows me to customize UX in any way imaginable, and that is absolutely necessary when designing prototypes. Another major reason for jQuery usage is coding through an interpreter that is legible, understandable, hence, intuitive. Explaining your code within the code is bright, let the minifiers and other assorted cleaners do the job of prepping your file for production.

    Now, one may gather that modern browsers offer pretty much the latest in javascript where jQuery is becoming redundant as far as cross-browser compatibility issues, but jQuery offers much more than that, and I foresee a future where jQuery should align its sturdy cross-browserness priorities as the most user-friendly library possible that allows, among other things, novel and quickest element manipulation / traversing. There are many front-end designers out there like me, who want to delve into interactive SPA coding (not web pages), who may not have full knowledge of javascript (or none), but simply want to design their visions through code effortlessly, without the steep learning curves, constraints, and short shelf life of frameworks. In that respect, jQuery is way less overwhelming – a designer needs not be an expert programmer before learning and using jQuery.

    So jQuery remains relevant for us folks, and is awesome for SPAs and prototypes, take a look at what I’m currently up to here: http://www.danavangard.com. Let’s hope jQuery withstands the wrath of time by keeping core features and offering novelty instead of redundancy.

    jQuery All The Way!


Comments are closed.