New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the future of jQuery in 2018? #3886

Closed
thecodingdude opened this Issue Dec 11, 2017 · 15 comments

Comments

Projects
None yet
10 participants
@thecodingdude
Copy link

thecodingdude commented Dec 11, 2017

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

@timmywil

This comment has been minimized.

Copy link
Member

timmywil commented Dec 11, 2017

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.

@timmywil timmywil closed this Dec 11, 2017

@thecodingdude

This comment has been minimized.

Copy link
Author

thecodingdude commented Dec 11, 2017

Hi @timmywil, thanks so much for your reply, I was not expecting one so soon. I also do not mind you closing the issue since that is an elegant response that answers my main points. My other concern, however, is looking at the contributors graph. We can observe the trends from 2007 until today, 10 years later, where it's obvious a drop off has occurred.

If we take the last year we can see there were a total of 86 commits covering that period, with about ~5.8k additions and ~8.2k deletions.

Comparing this to the likes of Angular, React or VueJS it paints a pretty telling picture.

Of course I know numbers are not everything, but I think for a project this size, doing 100 commits in a year with a single blog post and not that much community interest and support maybe reveals the community doesn't see this as the staple of the web as it once was - and that's okay, because maybe with the right focus this can be a library that only cares about the essential, and removes any left over cruft (ajax, animations, etc). The syntax is lovely, so maybe there is a place for a redefined jQuery with the likes of Angular/React/Vue.

Cheers and thanks for your informative reply.

@timmywil

This comment has been minimized.

Copy link
Member

timmywil commented Dec 11, 2017

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.

@dmethvin

This comment has been minimized.

Copy link
Member

dmethvin commented Dec 12, 2017

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.

@thecodingdude

This comment has been minimized.

Copy link
Author

thecodingdude commented Dec 12, 2017

What is jQuery not doing that people think it should do?

For me, the reason I made this issue was due to a lack of communication/activity, and what the roadmap was going forward in regards to jQuery and modern web features. I agree that jQuery isn't going anywhere for a while, I can only hope as the codebase ages even further this can be adapted so that jQuery that takes advantage of new web platform features. I think we can all agree XHR had its day and window.fetch is the native replacement :).

I think there's not much more to be said, apart from wait and watch what happens in the coming years.

@amnond

This comment has been minimized.

Copy link

amnond commented Jan 18, 2018

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.

@dotnetshadow

This comment has been minimized.

Copy link

dotnetshadow commented Feb 1, 2018

@timmywil Thanks for your explanation on the future of jQuery, we appreciate the efforts of all especially when most have full time jobs. In terms of jQuery 4.0 release are you thinking end of 2018? or the year after?

@timmywil

This comment has been minimized.

Copy link
Member

timmywil commented Feb 1, 2018

@dotnetshadow Yep, we're thinking of at least getting a beta out for 4.0 end of this year.

@manual63

This comment has been minimized.

Copy link

manual63 commented May 23, 2018

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.

@jqdan

This comment has been minimized.

Copy link

jqdan commented May 31, 2018

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: 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!

DA

@codedumps

This comment has been minimized.

Copy link

codedumps commented Sep 17, 2018

jquery - это рак, который порожает мозг и отупляет. резига ждут ад и анальная пенетрация за то что он породил миллионы дебилов

@banana-in-a-box

This comment has been minimized.

Copy link

banana-in-a-box commented Sep 21, 2018

Angular (which is dying)

Quite patently incorrect.

@banana-in-a-box

This comment has been minimized.

Copy link

banana-in-a-box commented Sep 21, 2018

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.

This does not make sense. Am using Babel with TypeScript with @types/jquery.

Have a feeling there's a lot of misinformation floating around!

@guylando

This comment has been minimized.

Copy link

guylando commented Oct 22, 2018

Its been previously told that there will be a new version release every 6 months and yet there wasn't one for almost a year so how does this stand together with the claims that jquery is not dying?
When will the next jquery version be released?

@timmywil

This comment has been minimized.

Copy link
Member

timmywil commented Oct 22, 2018

We are close to a 3.4 release and should have it out in the coming weeks. But whether jQuery is "dying" is not a question of how often there are releases, but whether it still has enough users to warrant maintenance, and the latter will be true for a long time to come. Anyway, I think this issue has served its original purpose.

@jquery jquery locked as resolved and limited conversation to collaborators Oct 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.