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 basic building blocks of the approach - have been available and stable for a long time.

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.

I pretty much use HTMX and vanilla JS to solve most problems, when I use Django at least. Keeps things simple and gives that SPA feel to the app too.

The problem with jQuery is that, being imperative, it quickly becomes complex when you need to handle more than one thing because you need to cover imperatively all cases.

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.

What's wrong with React?

It made it so much better to build apps vs. spaghetti jQuery.

I still have nightmares about jeeping track of jQuery callbacks

by 2060 React Native should be up to v0.93

there are already de facto two Reacts. by 2060, there will be five.

It looks like it was done to not delay the 4.0 release. Since they follow semvar, that means it won't get the axe until 5.0 [1]. Pretty wild considering that 3.0 was released 10 years ago.

But maybe they will scope this one better: they were talking about getting 4.0 released in 2020 back in 2019!

[1]: https://github.com/jquery/jquery/pull/5077 [2]: https://github.com/jquery/jquery/issues/4299

Backwards compatibility. Apparently there are still some people stuck on IE11. It's nice that jQuery still supports those users and the products that they are still running.

Not everybody in the world can use modern hard- and software. There are tons of school computer labs running old software

Curious:

Whats the current behemoth instead of JQ?

I perceive it as still being the de-facto standard?

It is still used by many websites.

The terse and chainable jQuery syntax is more readable, easier to remember, and thus more pleasant to maintain. Rewriting for stdlib is easy, but bloats out the code by forcing you to pepper in redundant boilerplate on nearly every line.

Jquery does many things in one line that requires a couple lines of stdlib. Writing less code is what libraries are for.

What does jQuery provide that the Fetch API doesn’t?

jQuery made a messy ecosystem slightly less fragmented. Combined with CKEditor it effectively tamed a lot of web-developer chaos until nodejs dropped. =3

Not even modern vanilla JavaScript?

Zepto! That's a name I haven't heard in years. I don't remember how it happened but I'm still a member of the ZeptoJS org on Github.

WordPress ships with 3.x and is already looking to update to 4

I might argue the opposite. What would that have added to this release?

> Preact is only 4.7 kB

Is there some outlier place where people using virtual DOM frameworks don't also include 100-200kb of "ecosystem" in addition to the framework?

I suppose anything is possible, but I've never actually seen it. I have seen jQuery only sites. You get a lot for ~27kB.

jQuery does a lot more though, and includes support older browsers.