Live data from Hacker News

jQuery 4

blog.jquery.com

121–130 of 313 posts

Re: jQuery 4

#121
> includes some breaking changes

Most of the changes are completely reasonable - a lot are internal cleanup that would require no code changes on the user side, dropping older browsers, etc.

But the fact that there are breaking API changes is the most surprising thing to me. Projects that still use jQuery are going to be mostly legacy projects (I myself have several lying around). Breaking changes means more of an upgrade hassle on something that's already not worth much of an upgrade hassle to begin with. Removing things like `jQuery.isArray` serve only to make the upgrade path harder - the internal jQuery function code could literally just be `Array.isArray`, but at least then you wouldn't be breaking jQuery users' existing code.

At some point in the life of projects like these, I feel like they should accept their place in history and stop themselves breaking compatibility with any of the countless thousands (millions!) of their users' projects. Just be a good clean library that one can keep using without having to think about it forever and ever.

Re: jQuery 4

#122
post #93

Earlier quoted context omitted.

These days I’ve moved to native JS, but hot damn the $() selector interface was elegant and minimal vs document.getElement[s]by[attribute)]. While presumably jquery is slower than native selectors, maybe that could be pre-computed away.

In case you missed them: check out querySelector and querySelectorAll. They are closer to what the jQuery selector system does, and I think they were inspired by it. If the verbosity bothers you, you can always define an utility function with a short name (although I'm not personally a fan of this kind of things). https://developer.mozilla.org/docs/Web/API/Document/querySel... https://developer.mozilla.org/docs/Web/A…

body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.

Re: jQuery 4

#123

Earlier quoted context omitted.

Yet it would still run Windows Adware edition. =3

Use Enterprise

Enterprise Adware? Sounds hilarious to people that already paid $190 USD/seat to get spammed.

In general, Windows has always belonged on a VM snapshot backing image. =3

Re: jQuery 4

#124
I thought this would include more drastic changes, but it seems that this is more house cleaning stuff, like, "nobody should really be using this in 2026". They are providing a library for someone who really likes jQuery and wants to use it over something like React. (Which is completely fine and reasonable.)

Looks like the core behavior doesn't change, something that people complain about, e.g. https://github.blog/engineering/engineering-principles/remov...

> This syntax is simple to write, but to our standards, doesn’t communicate intent really well. Did the author expect one or more js-widget elements on this page? Also, if we update our page markup and accidentally leave out the js-widget classname, will an exception in the browser inform us that something went wrong? By default, jQuery silently skips the whole expresion when nothing matched the initial selector; but to us, such behavior was a bug rather than a feature.

I completely agree with this, because I have been bitten so many times by this from subtle bugs. However I can see some other people not caring about any of it.

I already know that I am definitely not going to use jQuery in my personal projects, and there is no chance that my workspace does. (I much prefer letting a framework handle rendering for me based on data binding.) So none of that concerns me. But good luck to jQuery and anyone who sticks with it.

Re: jQuery 4

#125

> includes some breaking changes Most of the changes are completely reasonable - a lot are internal cleanup that would require no code changes on the user side, dropping older browsers, etc. But the fact that there are breaking API changes is the most surprising thing to me. Projects that still use jQuery are going to be mostly legacy projects (I myself have several lying around). Breaking changes means more of an up…

I don’t understand your use case. If you’ve got legacy projects that you don’t want to touch, why upgrade a dependency to a new major version? You can keep using jquery without having to think about it. Just keep using version 3.7 and don’t even think about version 4.

Re: jQuery 4

#126
What is the usecase for this in the age of React, NextJS? And for static sites we have Astro etc. And even if you need something simple why use jQuery? Vanila JS has better API now. Am I missing anything?

Re: jQuery 4

#127
post #98

Earlier quoted context omitted.

Curious: Whats the current behemoth instead of JQ? I perceive it as still being the de-facto standard?

Many things JQ introduced are browser native now.

Or can be replaced by other technologies, like CSS animations that replace jQuery animation code with just addClass/removeClass.

Re: jQuery 4

#128
jQuery was very useful when many features were missing or not consistent/standardized between browsers. Nowadays, JS / DOM API is very rich, mature and standardized. So, jQuery is not as necessary as it was before.

https://youmightnotneedjquery.com/

Yes, sometimes the vanilla JS analogs are not the most elegant, but the vast majority are not terribly complicated either.

IMHO, another advantage of vanilla JS (aside from saving ~30KB) is potentially easier debugging. For example, I could find / debug the event listeners using the dev tools more easily when they were implemented via vanilla JS, since for complicated event listeners I had to step through a lot of jQuery code.

Re: jQuery 4

#129
That bit about focus event order gave me flashbacks and raised my heart rate by a couple of bpm. Had some bad times with that ~15 years ago!

Re: jQuery 4

#130
post #93

Earlier quoted context omitted.

In case you missed them: check out querySelector and querySelectorAll. They are closer to what the jQuery selector system does, and I think they were inspired by it. If the verbosity bothers you, you can always define an utility function with a short name (although I'm not personally a fan of this kind of things). https://developer.mozilla.org/docs/Web/API/Document/querySel... https://developer.mozilla.org/docs/Web/A…

body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.

Please don't mess with native prototypes though.
Post reply on HN