Live data from Hacker News

jQuery 4

blog.jquery.com

171–180 of 313 posts

Re: jQuery 4

#171

Earlier quoted context omitted.

It's overly verbose, unintuitive and in 2025, having a virtual dom is no longer compulsory to write interactive web apps. If you want to write modern web apps, you can use Svelte. If you want to write web apps truly functionally, you can use Elm. React is the jQuery of our times. It was really helpful in the Angular era but we are living at the dawn of a new era now.

Svelte looks good at first until you realize that to get the best support and features you're basically required to use the meta framework SvelteKit which sucks.

Well yes but that's not related to React: Svelte = React.

Re: jQuery 4

#172

> 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.

To fix vulnerabilities?

I recently had to upgrade from jQuery 2 to the latest version, because an client demanded it (security issues), and just ran into compatibility issues with third party libs/plugins.

Re: jQuery 4

#174
post #51

Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.

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.

const $ = document.querySelectorAll

Re: jQuery 4

#175
Ive never been a frontend guy, although I was a heavy user of jquery when I needed it. But I cant help but stick to my roots.... LONG LIVE PROTOYPE!

Re: jQuery 4

#176
post #152

Earlier quoted context omitted.

This is the part that I find the strangest: > We also dropped support for other very old browsers, including Edge Legacy, iOS versions earlier than the last 3, Firefox versions earlier than the last 2 (aside from Firefox ESR), and Android Browser. Safari from iOS 16, released in 2022, is more modern in every conceivable way than MSIE 11. I'd also bet there are more people stuck with iOS 16- than those who can only us…

There are a lot of intranet web applications that require IE, and IE is still in support by Microsoft. Even on Windows 11 Edge still has IE Mode for that reason. IPhones stuck on older iOS version by definition aren’t supported by Apple anymore.

Use those browsers for the internal undead apps, but a modern browser for the Internet.

Those phones are still supported. The most recent iOS 16 update was in September 2025.

Re: jQuery 4

#177
post #88

Earlier quoted context omitted.

According to Cloudflare, there are almost no users still on MSIE of any version.[0] Statcounter says there are about 4.6% of iOS users still on iOS 16.[1] My gut instinct is that there are multiple times more people using iOS 16 today than MSIE of any version. [0] https://radar.cloudflare.com/reports/browser-market-share-20... [1] https://gs.statcounter.com/os-version-market-share/ios/mobil...

IIRC public counters tend to miss corporate networks.

A jQuery update would miss those quarantined browsers, too.

Re: jQuery 4

#178
post #23

Earlier quoted context omitted.

I used this approach before and it indeed works better than the 2010-style jQuery mess. A good fit for userscripts too, where the problem you attempt to solve is fairly limited and having dependencies, especially with a build steps, is a pain. Note that you don't need jQuery for this at all, unless you are somehow stuck with ancient browser support as a requirement - querySelector, addEventListener, innerHtml - the b…

Unfortunately, nowadays writing userscripts is much harder than it used to be. Most websites are using some sort of reactive FE framework so you need to make extensive use of mutationObservers (or whatever the equivalent is in jQuery I guess).

I'm not a frontend dev but I came up with this and use it a lot in my userscripts. It's not the most efficient (it can certainly be refactored to create a MutationObserver singleton and then have each call hook into that) but it works well enough for my needs and lets me basically use an old-school to dealing with reactive sites (so long as you are fine with using async):

    function awaitElement(selector) {
        return awaitPredicate(selector, _ => true);
    }

    function awaitPredicate(selector, predicate) {
        return new Promise((resolve, _reject) => {
            for (const el of document.querySelectorAll(selector)) {
                if (predicate(el)) {
                    resolve(el);
                    return;
                }
            }

            // Create a MutationObserver to listen for changes
            const observer = new MutationObserver((_mutations, obs) => {
                // You could search just inside _mutations instead of the entire DOM.
                // Efficiency will depend primarily on how precise your selector is.
                for (const el of document.querySelectorAll(selector)) {
                    if (predicate(el)) {
                        resolve(el);
                        obs.disconnect(); // Don't forget to disconnect the observer!
                        break;
                    }
                }
            });

            // Start observing the document
            observer.observe(document.documentElement, {
                childList: true,
                subtree: true,
                attributes: false,
                characterData: false,
            });
        });
    }

Re: jQuery 4

#179
post #153

Earlier quoted context omitted.

Oh, certainly, corporations run ten-year-old software. But for the record, IE 11 turns 13 this year [1]. Which makes it somewhat more surprising to me. [1] https://en.wikipedia.org/wiki/Internet_Explorer_11

Microsoft will support IE 11 until 2032.

My reading is that they’ll support Edge’s IE 11 compatibility mode until then, but that IE 11 is already EOLed except for a couple of extremely niche enterprise versions.

Re: jQuery 4

#180

Related: This is a nice write-up of how to write reactive jQuery. It's presented as an alternative to jQuery spaghetti code, in the context of being in a legacy codebase where you might not have access to newer frameworks. https://css-tricks.com/reactive-jquery-for-spaghetti-fied-le...

This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. In retrospect, over-engineered React code can be worse than decently organized jQuery code, but some jQuery mess was worse than any React code. So I guess I'm saying, React did raise the bar and standard of quality - but it can get to be too much, sometimes a judicious use of old familiar tool gets the job done.

You reminded me of a time where one of my clients asked me to add a feature on a file uploader written in react/redux. This was early 2021.

I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways, the form literally had a textual input, a button to open the file explorer and a submit button.

It took few weeks one of their Romanian team to build it and apparently that team was reassigned and nobody could touch it without them.

I remember writing pages and pages of notes to understand how this all tied up in those extremely complex chains and claiming progress after few hours when I achieved to simplify the flow by removing a handful of these actions. Hooray.

Then it suddenly dawned on me that...I could just rewrite it from scratch.

Nuked the entirety of that nonsense and replaced it with a single useState in a matter of few hours also implemented the newly requested features.

The client could not believe my progress and the fact I also removed many of their previous issues.

Then I had a second realization: React was useless too and it got dropped for native HTML forms and a handful of JS callbacks.

Post reply on HN