For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See "http://eyeandtea.com/crxcmp" for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of admitting to them. The shadow DOM is one example. JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.
Having said that, after JQuery 1.x, and in particular, the changing, the deprecating, and the dropping of things here and there, JQuery no longer made sense. Somewhat similar to the SDL situation in the C/C++ word. An important role of JQuery, similar to SDL, was a strong code contract before anything else, and if the developer now has to account for JQuery's version differences like having to account for browser differences, what is the point.
Dont get me wrong - I really like and appreciate your comment.
However, and adding to other replies, by SDL I assume you mean the Simple Directmedia Layer?
SDL looks rather strong from my perspective and still my typical goto when having fun making a game. You could argue SDL lost some customers in favour of other libraries like RayLib - or moving away from making things from scratch to Unreal, Unity, etc.
SDL still seems popular - as SDL version 3 was officially released less than a year ago (or it feels like it)
However, I guess it depends what you need to do.
I do mean SDL, and the discussion is not about its popularity, but about something formal, but perhaps I was not clear. First, yes, SDL is a very good library, and I have referred to them in the past for references about issues related to software architecture.
However, the way I saw SDL 1.x, I am expecting a strong contract. Every now and then SDL drops support for one thing or another. Where you had to worry about different APIs, now if you want to retain your strong contracts, you have to worry about different SDL versions. I am aware of something like the "sdl12-compat" layer for example, somewhat similar to JQuery Migrate, but it does not change the fact that the underlying contract is not strong, is not trustworthy, because of both changing APIs and changing compatibility, similar to the JQuery situation.
> JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.
It is the ability that JQuery gave us to scope the css selector to a particular node. If you know POSIX, similar to the "at" functions for filesystems. By CSS child selector, classes, IDs, and what JQuery gave us, you could already develop self contained components, HTML custom elements if you like, without the need for shadow DOM. If you teach people to write well defined CSS, they argue that the CSS is over qualified and similar nonsense. Then the industry turns around and invents the shadow DOM. Any fool can come up with a complicated solution, but the best mind comes up with the simplest. And simplicity is not easy.
Take a careful look at "http://eyeandtea.com/crxcmp", and see how the need for shadow DOM is completely absent.
And this simple thing is just one of the geniuses exposed by JQuery.
SDL is very relevant. Not just on PC, also on consoles as ports for all modern consoles are available to platform disclosed developers. (See READMEs in SDL repository.) Calling SDL outdated / irrelevant is definitely an overstatement despite most developers using UE or Unity nowadays.
Congrats to everyone involved in the jQuery 4.0 release.
For what it’s worth, if you’re looking for a more structured approach on top of jQuery, JsViews (https://jsviews.com) provides a reactive templating and data-binding system that’s been around and stable for many years.
It hasn’t seen the same level of adoption as newer frameworks, but it may still be of interest to people who prefer the jQuery ecosystem.
That looks interesting, I'm not likely to write any jQuery any time soon, but I'll check out the source code to see if I can learn anything from it.
Regarding adoption levels, the JsViews website made me think I had accidentally toggled the "Desktop Site" option in my Iceweasel browser, I wonder if that scared people off. Or perhaps it's because, as others mentioned, most jQuery development these days is in legacy codebases where the devs are not allowed to add any new libraries, reducing the adoption rates of any new jQuery libraries even more than you'd expect based on the raw nrs of jQuery users.
(the website does work though, and it loads fast. Which is something I've always appreciated about jQuery based sites still alive today. The only thing I'm missing is any indication of how big it is when minified + gzipped. EDIT: jsrender.js is 33.74 kB, jsrender.min.js a mere 12.82 kB)
I’ve been collaborating with Boris, the author of JsViews, and we do have plans to modernize the website—which speaks directly to your point about first impressions and adoption. You’re absolutely right that presentation matters; if something looks dated, people may disengage before digging any deeper.
I also raised the jQuery dependency concern with Boris for exactly the reason you mentioned: many teams automatically rule out anything that requires jQuery, especially outside of legacy codebases. That’s a real barrier today.
For what it’s worth, a jQuery-free version may happen. Boris is actively exploring it, but he’s making no promises—it’s a non-trivial problem and would effectively require a full rewrite rather than a simple refactor.
I’ve found similar quality in the more recent Storybook upgrade tools - clean CLI wizard, clear error messages, and it does a good job of examining your setup and letting you know what it can and can’t upgrade automatically, with clear instructions on the parts you need to handle yourself.
I love tech hype cycles haha, I remember when you got laughed at for using jquery and now it seems everyone’s burned out and happy to go back to a simpler time
Someone should just hook up a virtual dom to jQuery, it's got a whole plugin ecosystem that AI could really re-use. Jquery + Jquery UI + Jquery Plugins + AI is probably a super power we're all overlooking.
20 Years! I remember when jQuery first release I thought in 5 to 10 years time we wont need jQuery because everything jQuery has will be built into the browser or becomes part of HTML Spec.
But then Google, Chrome, iPhone, PWA or JS for everything took over and took a completely different path to what I imagine webpage would be.
Everything I ever used jquery for 15 years ago, I found myself able to do with the CSS and the JS standard library maybe 10 years ago. I honestly am confused when I see jquery used today for anything.
Is there still anything jquery does you cannot easily do with a couple lines of stdlib?
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's big point was to give a consistent API over inconsistent browser implementations, so it typically saves you from bites more often than it bites you.
jQuery, for as long as it's been around has had very few major releases, 4 now.. and very few breaking changes... hardly "biting" ... other than those sites that are injecting a half dozen different copies of jQuery from different modules, and who knows which one you're actually working with, let alone 3rd party payloads.
I mean, personally, I've mostly used React the past decade and any integration directly to the browser has been straight JS/TS... but I can still see how jQuery can be useful for its' conveniences.
which I found while doing some performance work at one point. intercooler.js started as a custom function that hooked .load() in based on custom attributes (a trick I learned from angular 1.x)
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).
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.
Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.
If you are an app or website developer, at least you won't break other's systems.
But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name.
Newer libraries start using that new standard method.
You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
It only works if you ever works on projects that have zero dependencies, or dependencies you never update.
Or you could spare yourself the troubles and define a method that takes the node in parameter.
It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library?
By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.
> You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.
Thanks for the feedback. But you did recommend a method that takes the node as a parameter. What protects me from that method name being claimed by some library later in the exact same way?
I used to use prototype (and sometimes scriptaculous)... Then came IE8 and broke the world on me.
For anyone that didn't know, IE8 implemented native JSON.(parse/stringify) methods, and the second parameter is a hydrator/dehydrator... however, if you added custom properties/methods to Array or Object prototypes, they would throw an error you couldn't catch in JS... so to work around, you'd have to load the JSON library and use it under a different name, in ALL your code, because the native implementation was locked/sealed and couldn't be masked out.
Second most annoying IE bug was 5.0.0 and the old/new api's for dealing with select elements. New worked, old broken, have fun.
I hate to sound like a webdev stereotype but surely the parsing step of querySelector, which is cached, is not slow enough to warrant maintaining such a build step.
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.
Yeah, that's the other HN koan about "You probably don't need React if..." But if you are using jquery/vanilla to shove state into your HTML, you probably actually do need something like react.
After having some time to think about it, I've seen some really perverse DOM stuff in jquery. Like $(el).next().children(3) type stuff. So I think this stuff really fell-over when there was 'too much state' for the DOM.
I think if you want to go high-dom manipulation a la jQuery, and want some form of complex state, storing the state _on_ the DOM might make sense? Things like data attributes and such, but I also feel like that’s itching for something more like htmx or maybe svelte (I’ve not looked into either enough, so I may be completely off base).
I do agree with the notion that jQuery is easy to mishandle when logic grows beyond a pretty narrow (mostly stateless) scope. It’s fantastic up until that point, and incredibly easy to footgun beyond it.
Part of me feels the same way, and ~2015 me was full on SPA believer, but nowadays I sigh a little sigh of relief when I land on a site with the aesthetic markers of PHP and jQuery and not whatever Facebook Marketplace is made out of. Not saying I’d personally want to code in either of them, but I appreciate that they work (or fail) predictably, and usually don’t grind my browser tab to a halt. Maybe it’s because sites that used jQuery and survived, survived because they didn’t exceed a very low threshold of complexity.
I'm mixed on HTMX for going a step beyond interactive forms, it's fine... but much more and I find HTMX and server-side Blazor for that matter really janky... button events with a round trip to the server can just feel wrong.
FWIW, also hated the old ASP.Net Webforms round trips (and omg massive event state on anything resembling dialup or less than a few mbps in the early 00's).
I just wish that React and other SPA devs kept some awareness of total payload sizes... I'm more tolerant than most, but you start crossing over/into MB of compressed JS, it's too much. Then that starts getting janky.
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.
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.
This sounds like an engineering quality problem rather than a tooling problem.
Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.
But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.
This brought back flashbacks of a brief moment when I was left as the sole maintainer of a “soon-to-be-axed-but-currently-critical” feature in a checkout flow developed by people who A) knew redux and B) were not me. They recently implanted some state updates before departing, and the bugs for that fell to me. I think I spent a few days tracing the code and understanding how they managed their state, and I think I needed to touch about five files to fully encompass the updates for one data point - I felt nuts!
"We'll build a big centralised store and take slices out of it" still feels like something you should eventually realise your app now needs rather than a starting point, even in libraries which do it without as much ceremony and indirection as Redux.
> The library seems to be an antipattern of indirection.
Auto-generated actions from slices are a codified way to do what was once considered an antipattern: Tying an action directly to a single reducer, instead of actions being an action the user could do on a page (which multiple reducers could respond to).
I really can't understand how someone would make 30 redux actions for a simple use case, as someone has implemented the exact same thing. But yes, not a fan of Redux myself
Many years ago, I used Redux to build real time streaming data processing layer. Basically I need to receive, merge, and process multiple data streams into a single realtime data pool. After that,consuming the realtime data becomes dead easy.
Even now I am not sure I could find a better tool to deal with real time data and synchronization. But for simple crud Redux is mostly overkill
you got to the crux of it. Redux became a trend, surfing on its popularity at a time React wasn't providing the reactive piece it needed, plus the time machine demo just amazed everyone. The author got his job at Facebook. It carried millions of developers to use that lib, the author even said it isn't necessarily the go to mechanism, but hiring manager stuck with the idea that all projects redux magicians, since all projects needed React.
For the anecdote, I remember my manager admitting we can't fix the legacy app, but we can put lipstick on the pig with React.
I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.
It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.
>> This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related.
To be fair, jQuery was a response to the the IE and JS variant mess of the early 2000s. jQuery made development possible without debugging across three browser varients.
React made complex interactive UIs a lot easier to manage than jQuery, but that resulted in many developers adding a lot more complexity just because they could.
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.
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,
});
});
}
Very true. I guess that depends on what websites you find issues with? I just checked mine and all of those are quality of life improvements for fully server rendered sites like HN or phpBB forums.
Yeah, I mostly use it for QoL improvements but for work related things. So Jira, Bitbucket, GitHub, Linear etc. basically whatever my employer uses. Back in the early 2010s most of that software was fully server rendered. Nowadays it's pretty rare for that to be the case.
I just try and get LLMs to do it for me because I'm lazy, and they like to use setInterval instead of mutationObservers and if it works, I just live with the inefficiency.
The Atlassian stack is particularly bad to extend IMHO given that there are sooooo many API endpoints that their UI calls and most of them are dog slow.
In ol'times people used BackboneJS[1] for that purpose. And surprisingly enough, it is still being actively supported[2].
If someone is still using jQuery for legacy reasons, BackboneJS might be a good intermediate step before going for a modern framework. Backbone is pretty light and pretty easy to grasp
There was a period where BackboneJS models were used as the datastore for React, before Redux took over. I haven't used it like this myself, but could definitely see it as a way to do an incremental rewrite.
That's a very nice pattern indeed. If you add signals, the update function even gets called automatically. That's basically what we do in [Reactive Mastro](https://mastrojs.github.io/reactive/) ;-)
The last major jquery app I wrote ended up using a similar reactive pattern. I had to shoehorn a custom search engine frontend into a Joomla CMS where I wasn’t allowed to change much. Good times!
But if you do that, you'll also find it easy to write plain JS without any libraries or frameworks. document.querySelectorAll is just slightly more verbose than $(). I have personally done this: for simple web pages, I just eschew all dependencies and write plain JS.
This is still the way - jQuery or not - for UI where you can't/don't want to use a component library. I use the same approach for my browser extensions, both for page scripts and options pages. Writing features so you update state then re-render also means you get things like automatically applying option changes live in page scripts, rather than having to reload the page, for free. Just receive the updated options and re-run everything.
Browser extension options pages are mostly a form mapped to what you have stored in the Storage API, so implementing them by handling the change event on a <form> wrapping all the options (no manual event listener boilerplate) then calling a render() function which applies classes to relevant elements (<body> classes are so good for conditionally showing/hiding things without manually touching the DOM), updates all form fields via named form.elements and re-generates any unique UI elements makes it so un-painful to change things without worrying you're missing a manual DOM update somewhere.
My options pages are Zen Garden-ing 5 different browser-specific UI themes from the same markup to match their host browsers, which is a brittle nightmare to maintain in an app which needs to change over time rather than static demo HTML, but once you've tamed the CSS, the state handling and re-rendering is so painless I'm sticking with it for a while yet, even though it would be long-term easier if I used Preact+htm for no-build option components which know what the active theme is and can generate specific UI for it.
My favourite dirty old-school knowledge is still the named global created for an element with an id, why bother selecting an element when it's right there (once you know you need to avoid global name collisions)?. I use those suckers all the time for quick fun stuff and one-off tool pages.
jQuery made a messy ecosystem slightly less fragmented. Combined with CKEditor it effectively tamed a lot of web-developer chaos until nodejs dropped. =3
The clean and simple syntax was always the reason to use jQuery. I remember seeing sites that were anti-JQ, so they'd show how you could replace a single jQuery line with 9 vanilla JS lines and uh... somehow this would improve things?
I can't believe how much public opinion has changed over the years. Love it, actually.
Complex APIs that require intimacy with internals with their gotchas.
Complex rendering model and hard to tame lifecycle since they ditched the class component. Very hard to get performant websites (but you're free to link me what you've produced with React and prove me wrong).
Also, biggest issue: severely misused for websites that are mostly static content and are nowhere near "app-like" nor have any particular reactivity need. 95%+ of react "applications" would've benefited from being written with a templating language instead.
E.g. Github was miles better under all aspects when it used ruby but of course somebody had to sell to upper management their promotion case.
In 2021, they published a post[0] about how they used web components, alongside a library called Calalyst. It seemed like quite a nice system. I've still seen include-fragment elements in the HTML, so I assume they still use it.
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.
As a non Elm lover, Why is that? I think you could freeze every JS frontend framework in time right now and use them for the next decade. JS is very backwards compatible.
It's the ones that do some kind of server connection that introduce vulnerabilities and need active development.
It's stuck in time, has no support, only core devs can expose newer DOM apis (and when I say newer I mean released in the last 6/7 years). Very hard to hire for, not LLM friendly.
I guess if every piece of tech you learn is about finding a job or using LLMs that might matter.
But again, I don't think no support matters. How many DOM apis do you know of in the last 10 years that are essential? There are sites on JQuery 2 running fine.
I enjoy being a Vue main in these discussions, mostly because everyone leaves us alone lol
I really enjoy the syntax of Vue over React, and if it’s an application that’s complex enough to warrant something like React I’ll almost always reach for Vue so long as it also meets the requirements.
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.
When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.
Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.
These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need without workarounds, and they're named in a way that make sense. [1]
And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change, even if components aren't subscribing to that state. Want subscriptions? Gotta hand-roll everything or use a 3rd party state library which don't support initialization before your components render if your global state depends on other state/data in React-land.
I'm all for people avoiding React if they want, but I do want to respond to some of this, as someone who has made a few React apps for work.
> When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.
Hooks didn't fundamentally change anything. They are ways to escape the render loop, which class components already had.
> Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.
Maybe because you don't necessarily need to. But for what it's worth, I'm on old versions of React when these weren't things, and I've built entire SPAs out without them at work. But reading their docs, they seem fine?
> And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change
I think it's good to give context on what a rerender is. It's not the same as repainting the DOM, or even in the same order of magnitude of CPU cycles. Your entire site could rerender from a text input, but you're unlikely to notice it even with 10x CPU slowdown in Devtools, unless you put something expensive in the render cycle for no reason. Indeed, I've seen people do a fetch request every time a text input changes. Meanwhile, if I do the same slowdown on Apple Music which is made in Svelte, it practically crashes.
But pretty much any other state management library will work the way you've described you want.
My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in.
Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above.
Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used.
Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!):
This is remarkably easy, and the best part is: I don't have to wrap my components with another <Context.Provider> component. I can... just use the hook! I sorely wish React offered a better way to wire up global or shared state like this. React doesn't even have a plugin system that would allow someone to port Pinia over to React. It's baffling.
Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.
You can use Tanstack Query or Zustand for this in React. They essentially have a global state, and you can attach reactive "views" to it. They also provide ways to delay rendering until you have the data ready.
It'll handle cancellation if your state changes while the query is being evaluated, you can add deferred rendering, and so on. You can even hook it into Suspense and have "transparent" handling of in-progress queries.
The downside is that mutations also need to be handled by these libraries, so it essentially becomes isomorphic to Solid's signals.
I've used React Query and Zustand extensively in my projects, and unfortunately Zustand suffers from the same issue in cases where you aren't dealing with async data. I'm talking about React state + data that's already available, but can't be used to initialize your store before the first render cycle.
Here's how Zustand gets around this, and lo-and-behold: it requires React Context :( [1] (Look at how much boilerplate is required!)
React Query at least gives you an `initialData` option [2] to populate the cache before anything is done, and it works similarly to `useState`'s initializer. The key nuance with `const [state, setState] = useState(myInitialValue)` is the initial value is set on `state` before anything renders, so you don't need to wait while the component flashes `null` or a loading state. Whatever you need it to be is there immediately, helping UIs feel faster. It's a minor detail, but it makes a big difference when you're working with more complex dependencies.
And you'd have to use `queryClient` to mutate the state locally since we aren't dealing with server data here.
But here's what I really want from the React team...
// Hook uses global instance instead of creating a new one each time it's used. No React Context boilerplate or ceremony. No wrapping components with more messy JSX. I can set state using React's primitives instead of messing with a 3rd party store:
const useGlobalStore = createGlobalStore(() => {
const dataFromAnotherHook = useAnotherHook();
const [settings, setSettings] = useState({
optionA: true,
optionB: dataFromAnotherHook,
});
return {
settings,
setSettings,
}
});
I think it might already be working like that? React now has concurrent rendering, so it will try to optimistically render the DOM on the first pass. This applies even if you have hooks.
They both will result in essentially the same amount of work. Same for calculations with useMemo(). It was a different situation before React 18, because rendering passes were essentially atomic.
How exactly is Vue better? It just introduces more artificial states, as far as I see.
My major problem with React is the way it interacts with async processes, but that's because async processes are inherently tricky to model. Suspense helps, but I don't like it. I very much feel that the intermediate states should be explicit.
I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance.
Their setup (component) functions are a staging ground for wiring up their primitives without you having to worry about how often each call is being made in your component function. Vue 3's composition pattern was inspired by React with hooks, with the exception that variables aren't computed on every render.
And I agree about Suspense, it's a confusing API because it's yet-another-way React forces you to nest your app / component structure even further, which creates indirection and makes it harder to tie things together logically so they're easier to reason about. The "oops, I forgot this was wrapped with X or Y" problem persists if a stray wrapper lives outside of the component you're working on.
I prefer using switch statements or internal component logic to assign the desired state to a variable, and then rendering it within the component's wrapper elements -- states like: loading, error, empty, and default -- all in the same component depending on my async status.
I tried proxy-based approaches before (in Solid) and I _also_ had a lot of problems with async processes. The "transparent" proxies are not really transparent.
I understand that mixing declarative UI with the harsh imperative world is always problematic, but I think I prefer React's approach of "no spooky action at a distance".
As for speed, I didn't find any real difference between frameworks when they are used correctly. React can handle several thousand visible elements just fine, and if you have more, you probably should work on reducing that or providing optimized diffing.
For example, we're using React for 3D reactive scenes with tens of thousands of visible elements. We do that by hooking into low-level diffing (the design was inspired by ThreeJS), and it works acceptably well on React.Native that uses interpreted JS.
I'm with you there -- I use React more than Vue day-to-day since most companies reach for it before anything else, so it's ubiquitous. Most devs simply don't have a choice unless they're lucky enough to be in the driver seat of a greenfield project.
I find React perfectly acceptable, it's just global state management and a few flaws with its lifecycle that repeatedly haunt me from time to time. (see: https://news.ycombinator.com/item?id=46683809)
Vue's downside is not being able to store off template fragments in variables. Every template/component must be a separate component file (or a registered component somewhere in the tree), so the ease of passing around HTML/JSX conditionally with variables is impossible in Vue. You can use raw render functions, but who wants to write those?
JSX being a first-class citizen is where React really shines.
I forgot to mention in my other reply, but if you find yourself needing to render a massive list performantly, check out TanStack Virtual. It's a godsend!
I use Preact, in the old-school way, without any "use-whatever" that React introduced. I like it that way. It's simple, it's very easy, and I get things done quickly without over-thinking it.
It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears).
Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.
> Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.
It kills me to think of how amazing Web Components could be if those folks had started standardising them _now_ instead of in "competition" with userland component libraries of the time (while punting on many of the essential challenges of developing UI in the DOM those libraries were still evolving solutions for), and introduced more problems entirely of their own making.
Too bad the problems getting solved aren't the problems that need solving. Maybe this is one of the reasons software development is such a joke of a profession.
Speaking of which, is there a Tailwind CSS equivalent for React Native? I find passing `style` objects around (ala CSS Modules) to be a pain after using Tailwind for so long in web projects.
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.
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.
Upload progress. The Fetch API offers no way observe and display progress when uploading a file (or making any large request). jQuery makes this possible via the `xhr` callback.
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!
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.
> 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 use IE 11, except maybe at companies with horrid IT departments, in which case I kind of see this as enabling them to continue to suck.
I'd vote to rip the bandaid off. MSIE is dead tech, deader than some of the other browsers they're deprecating. Let it fade into ignomony as soon as possible.
“Support” here probably means “we’re testing jQuery for compatibility on those web browsers” - likely Safari from iOS 16 still runs this version of jQuery just fine. However, running automated test suites or support bugfixing for those clients is a lot harder than spinning up some Microsoft-provided VM with IE11 on it.
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.
> There are likely to be no devices running iOS 16
My iPhone X is stuck on iOS 16 with no way to upgrade.
However, the phone is still working well. Despite being in daily use for 8 years it still has 81% battery capacity, has never been dropped, has a great OLED screen, can record 4K@60 video. It is far more responsive than a brand new 2025 $200 Android phone from e.g. Xiaomi. It still gets security patches from Apple. The only real shortcoming compared to a modern iPhone is the low light camera performance. That and some app developers don't support iOS 16 anymore, so e.g. I can't use the ChatGPT app and have to use it via the browser, but the Gemini app works fine.
I visited a distillery in 2020. Their machines were managed by HP laptops running Windows XP. Those machines and those laptops and that Windows XP are probably still there with their old IE browser.
They will probably be there for as long as the capacitors last, but the critical thing is that they are almost certainly running some Win32 industrial process software with no need for web browsers or for that matter even Internet connectivity. In fact I hope they’re not on wifi given the state of legacy WinXP security!
There are some really retrograde government and bigcorps, running ten year old infrastructure. And if that is your customer-base? You do it. Plus I worked on a consumer launch site for something you might remember, and we got the late requirement for IE7 support, because that's what the executives in Japan had. No customers cared, but yeah it worked in IE7.
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.
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.
I think anything still using ActiveX like stuff or "native" things. Sure, it should all be dead and gone, but some might not be and there is no path forward with any of that AFAIK.
Surely by this point someone has written a 0-day for MSIE 11 which gets root and silently installs an Internet Explorer skinned Chromium. If not, someone should get onto that. —Signed, everyone
JQuery is cool because it does not try to replace the HTML. Progressive_Enhancement / Graceful Degradation is possible with jQuery, something which the new Frameworks, Svelte, React, etc., have forgotten / never learned.
It's amazing how much jQuery is still used today. Even on modern websites you can often find it included (browser devtools -> jQuery in the console, and see). And not just on hobbyist sites, but on serious company websites and their web tools as well.
Nearly every time I write something in JavaScript, the first line is const $ = (selector) => document.querySelector(selector). I do not have jQuery nostalgia as much as many others here, but that particular shorthand is very useful.
For extra flavor, const $$ = (selector) => document.querySelectorAll(selector) on top.
That changelog is wild; it closes out dozens of issues that have been open on Github for 5+ years. I assume that's related to this being the first new major version in years.
Has anyone done any benchmarks yet to see how jQuery 4 compares to jQuery 3.7?
Much like I am sure anyone else who started doing web dev in the 2000s and 2010s before SPA frameworks were as prevalent I learned web development scripting with jQuery and I am happy to see its still around. Theres so many things I built on top of jQuery in those early years that likely still work. Kudos to the team.
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.
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.
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.
I was surprised that for most of my smaller use cases, Zepto.js was a drop-in replacement that worked well. I do need to try the jQuery slim builds, I've never explored that.
Prototype was great when it first landed but I found jQuery to be so much more elegant and fluid. For example, the overloaded $(...) which I'm pretty certain we have to thank for querySelectorAll.
I used jQuery for the past ~ 10 years on smaller apps and I had no problems with it. Then I slowly replaced it with modern JS wherever possible and I found that today I am using jQuery only because Datatables.js depends on it.
It was a nice ride, many thanks to the people that worked and still work on it. Not sure we'll ever see a jQuery 5, but that's life.
Wow, this is interesting to see. I thought jQuery was dead.
My next question would be, is this something that OpenAI and Anthropic would train their data on? If I ask Claude Code to write an app and utilize jQuery, would it resolve to the previous version until it's retrained in a newer model?
Congrats on shipping!!!! It's been a long time since I've written any jQuery but I remember how wonderful it was to work with in the age of browser inconstancies. Thank you EJohn and the team for continuing the project.
I remember the first time I tried jQuery -- which was 2009.
Before jQuery, I had vanilla JS code that factored in Safari, Firefox, Opera... and... IE6, IE7, and then IE8 which was (from memory) recent at the time.
Trying to design a visual drag n' drop editing interface on the web was a chore at the time especially with the differences in IE browsers! It was suprising how many customers were still using IE6!
A lot of this is purely by memory, now. I even have shivering memories reminding myself I was using VB.NET with ASP.NET Web forms. I really HATED it!
I remember ASP.NET provided dynamic web pages with things like Placeholder tag, etc. Again, It felt bloated even back then but I made it work. It was a balance of using what was recommended by other developers, and trying to ensure performance is good.
By around end of 2009, I tried jQuery as an experimental branch and very impressed with its capabilities. Despite being a decent Javascript developer at the time I was inexperienced with AJAX (Technically I was a Junior dev in ways) but jQuery shows me the way. It was not long before I ditched certain features of .NET Web Forms for jQuery.
At the time, there may have been a little overhead replacing various javascript code I am written with jQuery but the rewards were high. It was cleaner frontend and backend code, thanks to simple AJAX calls.
Since then I've always had huge respect for jQuery!
While I don't consider myself a decent javascript as I don't use it much. However, when I do come back to web development, I cannot be asked with the modern ways. To me it's bloat. I just stick with htmx, now. If I have do some fancy things visually then I will use jQuery.
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.)
> 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.
Don’t let all of the old heads glazing jquery in this thread confuse you - they’re just nostalgic. There’s no reason to even think of using jquery in 2026
Generally speaking, no, since a lot of what it does is now available natively, the odds that you'll need something from it are much lower.
There's probably some corner-case stuff it still makes easier if you're not using some framework, but I don't think there's a reason to go out of your way to use it just for the sake of using it.
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?
I do a lot of custom JS widget development, games, and utilities that are outside the context of a gigantic framework like React. Not everything is a a full-page SPA. Vanilla JS is indeed better than it was, but I found myself writing small JQ-like libraries and utilities to do tedious or even basic DOM manipulation, so I switched back to JQ and saved myself a lot of time and headaches. Compressed, minified JQ is also pretty small and is negligible in space consumption.
JQ is also used in frameworks like Bootstrap (although I think they’re trying to drop third-party dependencies like this since they tend to cause conflicts).
I have also used JQ in an Angular app where complex on-the-fly DOM manipulation just isn’t practical with standard tooling.
Hobbyists don’t want to learn every new framework. Someone can have a small business website for their activity and have been happy using jQuery since 2010.
jQuery is v4 now, but a lot of sites esp. wordpress still have 1.11 or 1.12 and only uses them to either doing modals(popover), show/hide(display), or ajax(fetch).
I use Preact for a very lean build for a front-end that lives in a small embedded MCU flash ROM. Gziped the whole front-end is about 25KB, including SVG images baked-in to the preact gzip file. I'm very careful about the libraries I include and their impact on the overall payload size.
I had started with a simple front-end that was using jQuery to quickly prototype the device controls, but quickly exceeded my goal of keeping the front-end at under 40KB total gzipped. The problem is needing more than just jQuery, we also needed jQueryUI to help with the front-end, or build out similar complex components ourselves. And as soon as the jQuery code became non-trivial, it was clear that Preact made much more sense to use. Our payload is quite a bit smaller yhan the jQuery prototype was.
For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See "http://eyeandtea.com/crxcmp" for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of admitting to them. The shadow DOM is one example. JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.
Having said that, after JQuery 1.x, and in particular, the changing, the deprecating, and the dropping of things here and there, JQuery no longer made sense. Somewhat similar to the SDL situation in the C/C++ word. An important role of JQuery, similar to SDL, was a strong code contract before anything else, and if the developer now has to account for JQuery's version differences like having to account for browser differences, what is the point.
Dont get me wrong - I really like and appreciate your comment.
However, and adding to other replies, by SDL I assume you mean the Simple Directmedia Layer?
SDL looks rather strong from my perspective and still my typical goto when having fun making a game. You could argue SDL lost some customers in favour of other libraries like RayLib - or moving away from making things from scratch to Unreal, Unity, etc.
SDL still seems popular - as SDL version 3 was officially released less than a year ago (or it feels like it) However, I guess it depends what you need to do.
I do mean SDL, and the discussion is not about its popularity, but about something formal, but perhaps I was not clear. First, yes, SDL is a very good library, and I have referred to them in the past for references about issues related to software architecture.
However, the way I saw SDL 1.x, I am expecting a strong contract. Every now and then SDL drops support for one thing or another. Where you had to worry about different APIs, now if you want to retain your strong contracts, you have to worry about different SDL versions. I am aware of something like the "sdl12-compat" layer for example, somewhat similar to JQuery Migrate, but it does not change the fact that the underlying contract is not strong, is not trustworthy, because of both changing APIs and changing compatibility, similar to the JQuery situation.
I think STL was the intent.
> JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.
Could you explain this please?
It is the ability that JQuery gave us to scope the css selector to a particular node. If you know POSIX, similar to the "at" functions for filesystems. By CSS child selector, classes, IDs, and what JQuery gave us, you could already develop self contained components, HTML custom elements if you like, without the need for shadow DOM. If you teach people to write well defined CSS, they argue that the CSS is over qualified and similar nonsense. Then the industry turns around and invents the shadow DOM. Any fool can come up with a complicated solution, but the best mind comes up with the simplest. And simplicity is not easy.
Take a careful look at "http://eyeandtea.com/crxcmp", and see how the need for shadow DOM is completely absent.
And this simple thing is just one of the geniuses exposed by JQuery.
I don't understand your comparison at all, SDL is a C library not a C++ library
Are you talking about STL? But even there it makes no sense
Wait, SDL is no longer relevant? What is the alternative?
SDL is very relevant. Not just on PC, also on consoles as ports for all modern consoles are available to platform disclosed developers. (See READMEs in SDL repository.) Calling SDL outdated / irrelevant is definitely an overstatement despite most developers using UE or Unity nowadays.
sdl is still alive and kicking, doesn't seem looking ground to new replacements?
Congrats to everyone involved in the jQuery 4.0 release.
For what it’s worth, if you’re looking for a more structured approach on top of jQuery, JsViews (https://jsviews.com) provides a reactive templating and data-binding system that’s been around and stable for many years.
It hasn’t seen the same level of adoption as newer frameworks, but it may still be of interest to people who prefer the jQuery ecosystem.
That looks interesting, I'm not likely to write any jQuery any time soon, but I'll check out the source code to see if I can learn anything from it.
Regarding adoption levels, the JsViews website made me think I had accidentally toggled the "Desktop Site" option in my Iceweasel browser, I wonder if that scared people off. Or perhaps it's because, as others mentioned, most jQuery development these days is in legacy codebases where the devs are not allowed to add any new libraries, reducing the adoption rates of any new jQuery libraries even more than you'd expect based on the raw nrs of jQuery users.
(the website does work though, and it loads fast. Which is something I've always appreciated about jQuery based sites still alive today. The only thing I'm missing is any indication of how big it is when minified + gzipped. EDIT: jsrender.js is 33.74 kB, jsrender.min.js a mere 12.82 kB)
I’ve been collaborating with Boris, the author of JsViews, and we do have plans to modernize the website—which speaks directly to your point about first impressions and adoption. You’re absolutely right that presentation matters; if something looks dated, people may disengage before digging any deeper.
I also raised the jQuery dependency concern with Boris for exactly the reason you mentioned: many teams automatically rule out anything that requires jQuery, especially outside of legacy codebases. That’s a real barrier today.
For what it’s worth, a jQuery-free version may happen. Boris is actively exploring it, but he’s making no promises—it’s a non-trivial problem and would effectively require a full rewrite rather than a simple refactor.
Never heard of JsViews but it looks interesting. For other "modern" jQuery approaches, I like cheerio and alpine myself:
https://cheerio.js.org/
https://alpinejs.dev/
I cannot express how much I admire the amount of effort jQuery puts into their upgrade tools.
I’ve found similar quality in the more recent Storybook upgrade tools - clean CLI wizard, clear error messages, and it does a good job of examining your setup and letting you know what it can and can’t upgrade automatically, with clear instructions on the parts you need to handle yourself.
Still one of my favourite libs on the whole planet. I will always love jQuery. It is responsible for my career in (real) companies.
Live on jQuery! Go forth and multiply!
I love tech hype cycles haha, I remember when you got laughed at for using jquery and now it seems everyone’s burned out and happy to go back to a simpler time
Haha, I remember that very clearly. Remember this?:
https://stackoverflow.com/questions/2826791/am-i-using-too-m...
all these kids chasing the new frameworks...jQuery and .NET framework have always kept me fed!
I mean… jQuery and .NET (6+) can still feed you very well :D
believe me if it was up to me I would get off framework this week hahaha
so true, 15 years of jQuery for me, it's my go to.
Someone should just hook up a virtual dom to jQuery, it's got a whole plugin ecosystem that AI could really re-use. Jquery + Jquery UI + Jquery Plugins + AI is probably a super power we're all overlooking.
The first time I read this I assumed you were joking about hooking up a virtual dom. But I think you're being serious.
Why hook up a virtual dom when you have a real one? Unless you're saying AI can't interact reliably with a real browser yet.
20 Years! I remember when jQuery first release I thought in 5 to 10 years time we wont need jQuery because everything jQuery has will be built into the browser or becomes part of HTML Spec.
But then Google, Chrome, iPhone, PWA or JS for everything took over and took a completely different path to what I imagine webpage would be.
Everything I ever used jquery for 15 years ago, I found myself able to do with the CSS and the JS standard library maybe 10 years ago. I honestly am confused when I see jquery used today for anything.
Is there still anything jquery does you cannot easily do with a couple lines of stdlib?
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.
Until you have to upgrade it and it bites you
jQuery's big point was to give a consistent API over inconsistent browser implementations, so it typically saves you from bites more often than it bites you.
jQuery, for as long as it's been around has had very few major releases, 4 now.. and very few breaking changes... hardly "biting" ... other than those sites that are injecting a half dozen different copies of jQuery from different modules, and who knows which one you're actually working with, let alone 3rd party payloads.
I mean, personally, I've mostly used React the past decade and any integration directly to the browser has been straight JS/TS... but I can still see how jQuery can be useful for its' conveniences.
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.
yes: htmx grew out of intercooler.js, which was based on jquery and inspired by the jQuery.load() method:
https://api.jquery.com/load/
which I found while doing some performance work at one point. intercooler.js started as a custom function that hooked .load() in based on custom attributes (a trick I learned from angular 1.x)
deeply respect and love jquery
Are you Carson?
yep
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/API/Document/querySel...
https://developer.mozilla.org/docs/Web/API/Element/querySele...
https://developer.mozilla.org/docs/Web/API/Element/querySele...
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.
Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.
If you are an app or website developer, at least you won't break other's systems.
But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name.
Newer libraries start using that new standard method.
You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
It only works if you ever works on projects that have zero dependencies, or dependencies you never update.
Or you could spare yourself the troubles and define a method that takes the node in parameter.
It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library?
By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.
> You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.
I'm discussing the "adding a prototype method" case and I'm explaining in my comment why this can be, in fact, an issue.
Thanks for the feedback. But you did recommend a method that takes the node as a parameter. What protects me from that method name being claimed by some library later in the exact same way?
We have a few oddly named methods for arrays and iterators because of the prototype and other libraries being very common.
Rules beget rules.
I used to use prototype (and sometimes scriptaculous)... Then came IE8 and broke the world on me.
For anyone that didn't know, IE8 implemented native JSON.(parse/stringify) methods, and the second parameter is a hydrator/dehydrator... however, if you added custom properties/methods to Array or Object prototypes, they would throw an error you couldn't catch in JS... so to work around, you'd have to load the JSON library and use it under a different name, in ALL your code, because the native implementation was locked/sealed and couldn't be masked out.
Second most annoying IE bug was 5.0.0 and the old/new api's for dealing with select elements. New worked, old broken, have fun.
The $ (and $$) selector functions live on in chrome/chromium devtools!
const $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);
Very simple jquery implementation with all the easy apis:
jQuery but gets compiled out like svelte... Not a bad idea at all.
I hate to sound like a webdev stereotype but surely the parsing step of querySelector, which is cached, is not slow enough to warrant maintaining such a build step.
Some things you build not because they are necessary, but because you can.
const $ = document.querySelectorAll
I usually do
and a similar one for $$.Probably have to bind the this value.
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.
Yeah, that's the other HN koan about "You probably don't need React if..." But if you are using jquery/vanilla to shove state into your HTML, you probably actually do need something like react.
It's not really about state but dom updates.
After having some time to think about it, I've seen some really perverse DOM stuff in jquery. Like $(el).next().children(3) type stuff. So I think this stuff really fell-over when there was 'too much state' for the DOM.
I think if you want to go high-dom manipulation a la jQuery, and want some form of complex state, storing the state _on_ the DOM might make sense? Things like data attributes and such, but I also feel like that’s itching for something more like htmx or maybe svelte (I’ve not looked into either enough, so I may be completely off base).
I do agree with the notion that jQuery is easy to mishandle when logic grows beyond a pretty narrow (mostly stateless) scope. It’s fantastic up until that point, and incredibly easy to footgun beyond it.
Part of me feels the same way, and ~2015 me was full on SPA believer, but nowadays I sigh a little sigh of relief when I land on a site with the aesthetic markers of PHP and jQuery and not whatever Facebook Marketplace is made out of. Not saying I’d personally want to code in either of them, but I appreciate that they work (or fail) predictably, and usually don’t grind my browser tab to a halt. Maybe it’s because sites that used jQuery and survived, survived because they didn’t exceed a very low threshold of complexity.
Facebook is PHP ironically.
It was once upon a time, hence them moving to HHVM to interpret it, but it’s been all but replaced with a PHP spinoff named Hacklang now.
I think in 2026 Facebook is a conglomeration of a bunch of things... Definitely not just PHP anymore.
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.
I'm mixed on HTMX for going a step beyond interactive forms, it's fine... but much more and I find HTMX and server-side Blazor for that matter really janky... button events with a round trip to the server can just feel wrong.
FWIW, also hated the old ASP.Net Webforms round trips (and omg massive event state on anything resembling dialup or less than a few mbps in the early 00's).
I just wish that React and other SPA devs kept some awareness of total payload sizes... I'm more tolerant than most, but you start crossing over/into MB of compressed JS, it's too much. Then that starts getting janky.
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.
> I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways
I 100% believe this, as it describes all the redux codebases I've seen. The library seems to be an antipattern of indirection.
This sounds like an engineering quality problem rather than a tooling problem.
Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.
Redux Toolkit has been a nice batteries-included way to use redux for a while now https://redux-toolkit.js.org/
But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.
I took a look at the quickstart guide at https://redux-toolkit.js.org/tutorials/quick-start and to me it still seems to add a lot of indirection.
This brought back flashbacks of a brief moment when I was left as the sole maintainer of a “soon-to-be-axed-but-currently-critical” feature in a checkout flow developed by people who A) knew redux and B) were not me. They recently implanted some state updates before departing, and the bugs for that fell to me. I think I spent a few days tracing the code and understanding how they managed their state, and I think I needed to touch about five files to fully encompass the updates for one data point - I felt nuts!
"We'll build a big centralised store and take slices out of it" still feels like something you should eventually realise your app now needs rather than a starting point, even in libraries which do it without as much ceremony and indirection as Redux.
> The library seems to be an antipattern of indirection.
Auto-generated actions from slices are a codified way to do what was once considered an antipattern: Tying an action directly to a single reducer, instead of actions being an action the user could do on a page (which multiple reducers could respond to).
I really can't understand how someone would make 30 redux actions for a simple use case, as someone has implemented the exact same thing. But yes, not a fan of Redux myself
Many years ago, I used Redux to build real time streaming data processing layer. Basically I need to receive, merge, and process multiple data streams into a single realtime data pool. After that,consuming the realtime data becomes dead easy.
Even now I am not sure I could find a better tool to deal with real time data and synchronization. But for simple crud Redux is mostly overkill
https://rxjs.dev/guide/observer
True but rx was even more niche than redux. It was much easier to hire redux devs
you got to the crux of it. Redux became a trend, surfing on its popularity at a time React wasn't providing the reactive piece it needed, plus the time machine demo just amazed everyone. The author got his job at Facebook. It carried millions of developers to use that lib, the author even said it isn't necessarily the go to mechanism, but hiring manager stuck with the idea that all projects redux magicians, since all projects needed React.
For the anecdote, I remember my manager admitting we can't fix the legacy app, but we can put lipstick on the pig with React.
Have some pity for those Senior Expert Architect Full-Stack Developers (fresh out of boot camp) in urgent need of job security.
The original developers weren't bootcampers but engineering graduates.
And in the same way faang is filled with leetcode blackbelt charlatans writing slop, so is Romania apparently.
Great generalization of an entire country's sector workforce.
I'm sure you'd 100% approve of such a statement of your country when based on one anecdotal recount (even if it true).
It's not about Romania or any other country.
I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.
It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.
I hear you saying that React raised the floor but also lowered the ceiling.
>> This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related.
To be fair, jQuery was a response to the the IE and JS variant mess of the early 2000s. jQuery made development possible without debugging across three browser varients.
Standardized selectors was the big use case for me
React made complex interactive UIs a lot easier to manage than jQuery, but that resulted in many developers adding a lot more complexity just because they could.
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.
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):
It's easier to write with LLMs. One-off projects (the way I treat userscripts) is where they really shine.
Oh the horrible things I do with Instagram...
go on
I often go for `setInterval` over `MutationObserver` because it works and I don't need instant reactivity and I don't have to think too much about it.
Very true. I guess that depends on what websites you find issues with? I just checked mine and all of those are quality of life improvements for fully server rendered sites like HN or phpBB forums.
Yeah, I mostly use it for QoL improvements but for work related things. So Jira, Bitbucket, GitHub, Linear etc. basically whatever my employer uses. Back in the early 2010s most of that software was fully server rendered. Nowadays it's pretty rare for that to be the case.
I just try and get LLMs to do it for me because I'm lazy, and they like to use setInterval instead of mutationObservers and if it works, I just live with the inefficiency.
The Atlassian stack is particularly bad to extend IMHO given that there are sooooo many API endpoints that their UI calls and most of them are dog slow.
In ol'times people used BackboneJS[1] for that purpose. And surprisingly enough, it is still being actively supported[2].
If someone is still using jQuery for legacy reasons, BackboneJS might be a good intermediate step before going for a modern framework. Backbone is pretty light and pretty easy to grasp
[1]: https://backbonejs.org/
[2]: https://github.com/jashkenas/backbone/tags
There was a period where BackboneJS models were used as the datastore for React, before Redux took over. I haven't used it like this myself, but could definitely see it as a way to do an incremental rewrite.
That's a very nice pattern indeed. If you add signals, the update function even gets called automatically. That's basically what we do in [Reactive Mastro](https://mastrojs.github.io/reactive/) ;-)
The last major jquery app I wrote ended up using a similar reactive pattern. I had to shoehorn a custom search engine frontend into a Joomla CMS where I wasn’t allowed to change much. Good times!
But if you do that, you'll also find it easy to write plain JS without any libraries or frameworks. document.querySelectorAll is just slightly more verbose than $(). I have personally done this: for simple web pages, I just eschew all dependencies and write plain JS.
This is still the way - jQuery or not - for UI where you can't/don't want to use a component library. I use the same approach for my browser extensions, both for page scripts and options pages. Writing features so you update state then re-render also means you get things like automatically applying option changes live in page scripts, rather than having to reload the page, for free. Just receive the updated options and re-run everything.
Browser extension options pages are mostly a form mapped to what you have stored in the Storage API, so implementing them by handling the change event on a <form> wrapping all the options (no manual event listener boilerplate) then calling a render() function which applies classes to relevant elements (<body> classes are so good for conditionally showing/hiding things without manually touching the DOM), updates all form fields via named form.elements and re-generates any unique UI elements makes it so un-painful to change things without worrying you're missing a manual DOM update somewhere.
My options pages are Zen Garden-ing 5 different browser-specific UI themes from the same markup to match their host browsers, which is a brittle nightmare to maintain in an app which needs to change over time rather than static demo HTML, but once you've tamed the CSS, the state handling and re-rendering is so painless I'm sticking with it for a while yet, even though it would be long-term easier if I used Preact+htm for no-build option components which know what the active theme is and can generate specific UI for it.
My favourite dirty old-school knowledge is still the named global created for an element with an id, why bother selecting an element when it's right there (once you know you need to avoid global name collisions)?. I use those suckers all the time for quick fun stuff and one-off tool pages.
MobX autoruns happily call jQuery functions.
The first time I truly enjoyed web development was when I got the hang of jQuery. Made everything so much simple and usable!
jQuery made a messy ecosystem slightly less fragmented. Combined with CKEditor it effectively tamed a lot of web-developer chaos until nodejs dropped. =3
jQuery was peak JavaScript.
Good times, I'm glad it is still around.
It is still used by many websites.
Indeed. Though a lot of its feature found their way into plain vanilla Javascript and browsers, the syntax is still so much easier with jQuery.
The clean and simple syntax was always the reason to use jQuery. I remember seeing sites that were anti-JQ, so they'd show how you could replace a single jQuery line with 9 vanilla JS lines and uh... somehow this would improve things?
I can't believe how much public opinion has changed over the years. Love it, actually.
Nice to see it still around and updated. The sad part is I guess this means React will be around in 2060.
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
Complex APIs that require intimacy with internals with their gotchas.
Complex rendering model and hard to tame lifecycle since they ditched the class component. Very hard to get performant websites (but you're free to link me what you've produced with React and prove me wrong).
Also, biggest issue: severely misused for websites that are mostly static content and are nowhere near "app-like" nor have any particular reactivity need. 95%+ of react "applications" would've benefited from being written with a templating language instead.
E.g. Github was miles better under all aspects when it used ruby but of course somebody had to sell to upper management their promotion case.
In 2021, they published a post[0] about how they used web components, alongside a library called Calalyst. It seemed like quite a nice system. I've still seen include-fragment elements in the HTML, so I assume they still use it.
[0]: https://github.blog/engineering/architecture-optimization/ho...
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.
Recommending Elm in 2025 is nonsense and I say it as an Elm lover.
As a non Elm lover, Why is that? I think you could freeze every JS frontend framework in time right now and use them for the next decade. JS is very backwards compatible.
It's the ones that do some kind of server connection that introduce vulnerabilities and need active development.
It's stuck in time, has no support, only core devs can expose newer DOM apis (and when I say newer I mean released in the last 6/7 years). Very hard to hire for, not LLM friendly.
I guess if every piece of tech you learn is about finding a job or using LLMs that might matter.
But again, I don't think no support matters. How many DOM apis do you know of in the last 10 years that are essential? There are sites on JQuery 2 running fine.
How is it overly verbose?
I find it very intuitive, with the exception of useEffect.
React's hello world:
```js
<div id="root"></div>
<script>
import React from 'https://esm.sh/react@19';
import ReactDOM from 'https://esm.sh/react-dom@19/client';
const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<h1>Hello, world!</h1>); </script>
```
---
HTML's hello world:
```html
<h1>Hello, world!</h1>
```
---
JS's hello world:
Nothing, it was already done in HTML
React:
import { useState } from "react";
function Counter() { const [count, setCount] = useState(0);
}---------- Svelte:
<script> let count = 0; </script>
<button on:click={() => count += 1}> Count: {count} </button> --------------- React: function Editor({ initialText }) { const [text, setText] = useState(initialText);
} --------------------- Svelte:<script> export let initialText; let text = initialText;
</script><textarea bind:value={text} />
No one's going to mention VueJS?
I enjoy being a Vue main in these discussions, mostly because everyone leaves us alone lol
I really enjoy the syntax of Vue over React, and if it’s an application that’s complex enough to warrant something like React I’ll almost always reach for Vue so long as it also meets the requirements.
Seeing Svelte 3/4 code always warms my heart. The ergonomics of `$:` are amazing.
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.
The problem with React is that it solved frontend.
So the options are to 1. Code React all day and be happy with it. 2. Come up with reasons why it's bad.
There are many talented and intellectually curious people in the field which lean towards 2.
The problem with React IMHO is it’s so dominant and so annoyingly over-engineered for many problems. I use Mithril and find it much less fuss.
When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.
Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.
These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need without workarounds, and they're named in a way that make sense. [1]
And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change, even if components aren't subscribing to that state. Want subscriptions? Gotta hand-roll everything or use a 3rd party state library which don't support initialization before your components render if your global state depends on other state/data in React-land.
1. https://vuejs.org/api/composition-api-lifecycle.html
I'm all for people avoiding React if they want, but I do want to respond to some of this, as someone who has made a few React apps for work.
> When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.
Hooks didn't fundamentally change anything. They are ways to escape the render loop, which class components already had.
> Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.
Maybe because you don't necessarily need to. But for what it's worth, I'm on old versions of React when these weren't things, and I've built entire SPAs out without them at work. But reading their docs, they seem fine?
> And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change
I think it's good to give context on what a rerender is. It's not the same as repainting the DOM, or even in the same order of magnitude of CPU cycles. Your entire site could rerender from a text input, but you're unlikely to notice it even with 10x CPU slowdown in Devtools, unless you put something expensive in the render cycle for no reason. Indeed, I've seen people do a fetch request every time a text input changes. Meanwhile, if I do the same slowdown on Apple Music which is made in Svelte, it practically crashes.
But pretty much any other state management library will work the way you've described you want.
My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in.
Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above.
Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used.
Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!):
This is remarkably easy, and the best part is: I don't have to wrap my components with another <Context.Provider> component. I can... just use the hook! I sorely wish React offered a better way to wire up global or shared state like this. React doesn't even have a plugin system that would allow someone to port Pinia over to React. It's baffling.Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.
You can use Tanstack Query or Zustand for this in React. They essentially have a global state, and you can attach reactive "views" to it. They also provide ways to delay rendering until you have the data ready.
Your example would look like:
It'll handle cancellation if your state changes while the query is being evaluated, you can add deferred rendering, and so on. You can even hook it into Suspense and have "transparent" handling of in-progress queries.The downside is that mutations also need to be handled by these libraries, so it essentially becomes isomorphic to Solid's signals.
I've used React Query and Zustand extensively in my projects, and unfortunately Zustand suffers from the same issue in cases where you aren't dealing with async data. I'm talking about React state + data that's already available, but can't be used to initialize your store before the first render cycle.
Here's how Zustand gets around this, and lo-and-behold: it requires React Context :( [1] (Look at how much boilerplate is required!)
React Query at least gives you an `initialData` option [2] to populate the cache before anything is done, and it works similarly to `useState`'s initializer. The key nuance with `const [state, setState] = useState(myInitialValue)` is the initial value is set on `state` before anything renders, so you don't need to wait while the component flashes `null` or a loading state. Whatever you need it to be is there immediately, helping UIs feel faster. It's a minor detail, but it makes a big difference when you're working with more complex dependencies.
1. https://zustand.docs.pmnd.rs/guides/initialize-state-with-pr...
2. https://tanstack.com/query/v5/docs/framework/react/guides/in...
---
I guess I could abuse React Query like this...
And you'd have to use `queryClient` to mutate the state locally since we aren't dealing with server data here.But here's what I really want from the React team...
I think it might already be working like that? React now has concurrent rendering, so it will try to optimistically render the DOM on the first pass. This applies even if you have hooks.
There is no real difference now between doing:
and: They both will result in essentially the same amount of work. Same for calculations with useMemo(). It was a different situation before React 18, because rendering passes were essentially atomic.Ah great point, I need to give this another shot and confirm. I only switched from 17 to 19 in the last few months here.
How exactly is Vue better? It just introduces more artificial states, as far as I see.
My major problem with React is the way it interacts with async processes, but that's because async processes are inherently tricky to model. Suspense helps, but I don't like it. I very much feel that the intermediate states should be explicit.
I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance.
Their setup (component) functions are a staging ground for wiring up their primitives without you having to worry about how often each call is being made in your component function. Vue 3's composition pattern was inspired by React with hooks, with the exception that variables aren't computed on every render.
And I agree about Suspense, it's a confusing API because it's yet-another-way React forces you to nest your app / component structure even further, which creates indirection and makes it harder to tie things together logically so they're easier to reason about. The "oops, I forgot this was wrapped with X or Y" problem persists if a stray wrapper lives outside of the component you're working on.
I prefer using switch statements or internal component logic to assign the desired state to a variable, and then rendering it within the component's wrapper elements -- states like: loading, error, empty, and default -- all in the same component depending on my async status.
I tried proxy-based approaches before (in Solid) and I _also_ had a lot of problems with async processes. The "transparent" proxies are not really transparent.
I understand that mixing declarative UI with the harsh imperative world is always problematic, but I think I prefer React's approach of "no spooky action at a distance".
As for speed, I didn't find any real difference between frameworks when they are used correctly. React can handle several thousand visible elements just fine, and if you have more, you probably should work on reducing that or providing optimized diffing.
For example, we're using React for 3D reactive scenes with tens of thousands of visible elements. We do that by hooking into low-level diffing (the design was inspired by ThreeJS), and it works acceptably well on React.Native that uses interpreted JS.
I'm with you there -- I use React more than Vue day-to-day since most companies reach for it before anything else, so it's ubiquitous. Most devs simply don't have a choice unless they're lucky enough to be in the driver seat of a greenfield project.
I find React perfectly acceptable, it's just global state management and a few flaws with its lifecycle that repeatedly haunt me from time to time. (see: https://news.ycombinator.com/item?id=46683809)
Vue's downside is not being able to store off template fragments in variables. Every template/component must be a separate component file (or a registered component somewhere in the tree), so the ease of passing around HTML/JSX conditionally with variables is impossible in Vue. You can use raw render functions, but who wants to write those?
JSX being a first-class citizen is where React really shines.
I forgot to mention in my other reply, but if you find yourself needing to render a massive list performantly, check out TanStack Virtual. It's a godsend!
I use Preact, in the old-school way, without any "use-whatever" that React introduced. I like it that way. It's simple, it's very easy, and I get things done quickly without over-thinking it.
It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears).
Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.
> Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.
It kills me to think of how amazing Web Components could be if those folks had started standardising them _now_ instead of in "competition" with userland component libraries of the time (while punting on many of the essential challenges of developing UI in the DOM those libraries were still evolving solutions for), and introduced more problems entirely of their own making.
Too bad the problems getting solved aren't the problems that need solving. Maybe this is one of the reasons software development is such a joke of a profession.
by 2060 React Native should be up to v0.93
there are already de facto two Reacts. by 2060, there will be five.
Two Reacts!?
The main divide now is client side React versus Server Components usually with a node.js backend
As someone who doesn't use React, there is React Native (for iOS & Android), and React (and that can be server-rendered or client-rendered).
There's also React Native Web
I'm sorry what
I find it is a good idea, it allows developers to cleanly define how to structure elements without random divs sneaking in.
It requires a strong design system and it probably makes it harder to use some web APIs but those can be reasonable tradeoffs
Speaking of which, is there a Tailwind CSS equivalent for React Native? I find passing `style` objects around (ala CSS Modules) to be a pain after using Tailwind for so long in web projects.
EDIT: Found one that's going v5 soon, looks nice. https://www.nativewind.dev/
In case you want to use React to make Web sites as well.
They should make a version of that runs as an app on a phone
They have one, it's called React Native Web Native
Twitter is built in React Native Web
There was also react vr
class components & function components.
That is the least interesting divide in the react community
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.
I still love the simplicity a ajax call can be done in Jquery
What does jQuery provide that the Fetch API doesn’t?
Upload progress. The Fetch API offers no way observe and display progress when uploading a file (or making any large request). jQuery makes this possible via the `xhr` callback.
Okay, your turn, script.aculo.us & Mootools.
there are 2 frameworks I haven't had of in some time.
Prototype
Unbelievably, still supports IE 11 which is scheduled to be deprecated in jQuery 5.0
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.
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 use IE 11, except maybe at companies with horrid IT departments, in which case I kind of see this as enabling them to continue to suck.
I'd vote to rip the bandaid off. MSIE is dead tech, deader than some of the other browsers they're deprecating. Let it fade into ignomony as soon as possible.
“Support” here probably means “we’re testing jQuery for compatibility on those web browsers” - likely Safari from iOS 16 still runs this version of jQuery just fine. However, running automated test suites or support bugfixing for those clients is a lot harder than spinning up some Microsoft-provided VM with IE11 on it.
Also, mobile phones get upgraded/upcycled much faster than desktop.
Fair point.
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.
It’s rarely a horrid IT department but some special or legacy software without modern replacement
But is this horrid legacy software really going to be pulling in a new major version of jQuery?
> Safari from iOS 16, released in 2022, is more modern in every conceivable way than MSIE 11.
There are likely millions if not tens of millions of computers still running MSIE11. There are likely to be no devices running iOS 16
> There are likely to be no devices running iOS 16
My iPhone X is stuck on iOS 16 with no way to upgrade.
However, the phone is still working well. Despite being in daily use for 8 years it still has 81% battery capacity, has never been dropped, has a great OLED screen, can record 4K@60 video. It is far more responsive than a brand new 2025 $200 Android phone from e.g. Xiaomi. It still gets security patches from Apple. The only real shortcoming compared to a modern iPhone is the low light camera performance. That and some app developers don't support iOS 16 anymore, so e.g. I can't use the ChatGPT app and have to use it via the browser, but the Gemini app works fine.
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...
I visited a distillery in 2020. Their machines were managed by HP laptops running Windows XP. Those machines and those laptops and that Windows XP are probably still there with their old IE browser.
They will probably be there for as long as the capacitors last, but the critical thing is that they are almost certainly running some Win32 industrial process software with no need for web browsers or for that matter even Internet connectivity. In fact I hope they’re not on wifi given the state of legacy WinXP security!
Those machines are probably not connected to the internet.
XP support IE8 max
IIRC public counters tend to miss corporate networks.
A jQuery update would miss those quarantined browsers, too.
Are those people/products upgrading jQuery though?
Who is still stuck on IE 11---and why?
There are some really retrograde government and bigcorps, running ten year old infrastructure. And if that is your customer-base? You do it. Plus I worked on a consumer launch site for something you might remember, and we got the late requirement for IE7 support, because that's what the executives in Japan had. No customers cared, but yeah it worked in IE7.
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.
The IE 11 desktop application remains supported on a number of Windows LTSC versions: https://techcommunity.microsoft.com/blog/windows-itpro-blog/... At least one of them, Windows 10 IoT LTSC, will receive support until 2032.
One of my clients in the past had, as of 2020, noticeable traffic from IE8, 9 and IE11. When I say noticeable I mean 10%+ out of million users.
It followed the 8-17 monday-friday pattern.
Essentially it was people at their work machines (posts, banks, etc) running corporate computers where modern browsers were not installed.
We had a computer for manually testing every release on IE8 and 9.
If somebody is looking for our products from those computers, we aren't gonna lose them.
But as far as I know, that client dropped support for IE8 and IE9 in 2024 with IE11 planned to be dropped this year.
Some corporate machines still run XP. Why upgrade what works?
SECURITY
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
I think anything still using ActiveX like stuff or "native" things. Sure, it should all be dead and gone, but some might not be and there is no path forward with any of that AFAIK.
Surely by this point someone has written a 0-day for MSIE 11 which gets root and silently installs an Internet Explorer skinned Chromium. If not, someone should get onto that. —Signed, everyone
Last available Chromium on XP has 0-days too, so not a big win.
The goal isn’t to make XP machines more secure, so that’s not a problem.
Microsoft will support IE 11 until 2032 in Windows 10 LTSC and IE Mode in Edge on Windows 11.
Not everybody in the world can use modern hard- and software. There are tons of school computer labs running old software
Yes, run jQuery 3.
Crazy to think that software running inside IE11 should use the latest version of a library.
JQuery is cool because it does not try to replace the HTML. Progressive_Enhancement / Graceful Degradation is possible with jQuery, something which the new Frameworks, Svelte, React, etc., have forgotten / never learned.
Vue can do progressive enhancement.
Yes, okay, some can. Vue, petite-vue, Alpine, ...
I remember being scared of jQuery and then being scared of vanilla JS. My, how time flies.
Incredible it's still being maintained.
Same experience I had! Impostor syndrome is a pain.
I love jQuery and it’s elegant methods chaining over object / array of DOM elements you keep in the chain.
15+ years ago I wrote a tutorial for french people about using jQuery, it got a lot of views. I hope it helped spread jQuery.
It's amazing how much jQuery is still used today. Even on modern websites you can often find it included (browser devtools -> jQuery in the console, and see). And not just on hobbyist sites, but on serious company websites and their web tools as well.
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.
jQuery is the last time I felt a library doing magic! Nothing has matched the feelings since then.
Not even modern vanilla JavaScript?
It's fairly close now but so much more verbose: ie document.getElementById('theID') vs $('#theID')
Nearly every time I write something in JavaScript, the first line is const $ = (selector) => document.querySelector(selector). I do not have jQuery nostalgia as much as many others here, but that particular shorthand is very useful.
For extra flavor, const $$ = (selector) => document.querySelectorAll(selector) on top.
That changelog is wild; it closes out dozens of issues that have been open on Github for 5+ years. I assume that's related to this being the first new major version in years.
Has anyone done any benchmarks yet to see how jQuery 4 compares to jQuery 3.7?
I personally don't have a need for JQuery anymore, but I still have a lot of respect for John Resig.
Much like I am sure anyone else who started doing web dev in the 2000s and 2010s before SPA frameworks were as prevalent I learned web development scripting with jQuery and I am happy to see its still around. Theres so many things I built on top of jQuery in those early years that likely still work. Kudos to the team.
> 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.
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.
I am still using jQuery.
I was surprised that for most of my smaller use cases, Zepto.js was a drop-in replacement that worked well. I do need to try the jQuery slim builds, I've never explored that.
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.
I really like that project! Why don't y'all hand it over to someone willing to do maintenance or at least archive it?
Who wants to do maintenance? Open an issue.
If you are using server side rendering is jQuery or native JS all you need or is is still worth looking into more complicated JS frontends?
htmlx[1] is the library for ssr nowadays, and TBH, pretty good option. It removes JS completely from the equation most of the time
[1]: https://htmx.org/
Yes, my default to go now is Django + Tailwind with HTMX and celery for background tasks. That alone took me far away.
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!
Prototype was great when it first landed but I found jQuery to be so much more elegant and fluid. For example, the overloaded $(...) which I'm pretty certain we have to thank for querySelectorAll.
I love jQuery syntax. It's still way tigheter than standards-based stuff, never understood all the crapping on it.
Long-time user here. It served me well for years, though I haven't really touched it since the 3.0 days. Glad to see it's still being maintained.
I love that they support ES6 modules, Trusted Types, and CSP! The clearing out of old APIs that have platform replacements is nice to see too!
I used jQuery for the past ~ 10 years on smaller apps and I had no problems with it. Then I slowly replaced it with modern JS wherever possible and I found that today I am using jQuery only because Datatables.js depends on it.
It was a nice ride, many thanks to the people that worked and still work on it. Not sure we'll ever see a jQuery 5, but that's life.
Wow, this is interesting to see. I thought jQuery was dead.
My next question would be, is this something that OpenAI and Anthropic would train their data on? If I ask Claude Code to write an app and utilize jQuery, would it resolve to the previous version until it's retrained in a newer model?
most code from jQuery 2 or 3 works in 4.
they have legendary backwards compatibility.
most of the breaking changes are dropping support for ancient browsers.
so yes, LLMs are great with jQuery.
Good ol' jQuery.
Thank you for everything you've done for us.
Congrats on shipping!!!! It's been a long time since I've written any jQuery but I remember how wonderful it was to work with in the age of browser inconstancies. Thank you EJohn and the team for continuing the project.
For us that started doing web apps as soon as the web was invented, JQ was a miracle.
Thanks guys!
"jQuery?!?! We use J-jQuery" -Jack Borrough (Senior Javascript Developer)
I had a boss around 2008 or so... "Why are you guys talking about JavaScript? Can't you just use jQuery instead?"
I feel so old. jQuery was hate/ok early in my career, as I started on the tail end of HTML5/in the middle of ES6 with all the new stuff.
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!
This is huge. jQuery is still my way to go for any website requiring some custom interaction that isn't available in vanilla js.
What isn't available in vanilla js?
I think it's probably a matter of things being easier: show()/hide() or simple animations versus futzing with style properties and CSS animations.
Hmm maybe i can finally move on from 2.x
I remember the first time I tried jQuery -- which was 2009.
Before jQuery, I had vanilla JS code that factored in Safari, Firefox, Opera... and... IE6, IE7, and then IE8 which was (from memory) recent at the time.
Trying to design a visual drag n' drop editing interface on the web was a chore at the time especially with the differences in IE browsers! It was suprising how many customers were still using IE6!
A lot of this is purely by memory, now. I even have shivering memories reminding myself I was using VB.NET with ASP.NET Web forms. I really HATED it!
I remember ASP.NET provided dynamic web pages with things like Placeholder tag, etc. Again, It felt bloated even back then but I made it work. It was a balance of using what was recommended by other developers, and trying to ensure performance is good.
By around end of 2009, I tried jQuery as an experimental branch and very impressed with its capabilities. Despite being a decent Javascript developer at the time I was inexperienced with AJAX (Technically I was a Junior dev in ways) but jQuery shows me the way. It was not long before I ditched certain features of .NET Web Forms for jQuery.
At the time, there may have been a little overhead replacing various javascript code I am written with jQuery but the rewards were high. It was cleaner frontend and backend code, thanks to simple AJAX calls.
Since then I've always had huge respect for jQuery! While I don't consider myself a decent javascript as I don't use it much. However, when I do come back to web development, I cannot be asked with the modern ways. To me it's bloat. I just stick with htmx, now. If I have do some fancy things visually then I will use jQuery.
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.
is there any reason to use jquery if you've never used it before
Don’t let all of the old heads glazing jquery in this thread confuse you - they’re just nostalgic. There’s no reason to even think of using jquery in 2026
Generally speaking, no, since a lot of what it does is now available natively, the odds that you'll need something from it are much lower.
There's probably some corner-case stuff it still makes easier if you're not using some framework, but I don't think there's a reason to go out of your way to use it just for the sake of using it.
if you need to sprinkle interactivity, jQuery is much more approachable than spa libraries like react.
maybe use Vue or something like mithril which doesn't require build. But jQuery is short and easy to grasp.
What's jquery? I only use dynamic drive for my DHTML
Amazing oss library, glad its still being maintained!
Meh. I was a Mootools connoisseur back in the day and saddened how jQuery became more popular.
I’m glad JavaScript has evolved to the point we don’t need jQuery anymore.
I wish it also included support for XPath Query.
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?
I do a lot of custom JS widget development, games, and utilities that are outside the context of a gigantic framework like React. Not everything is a a full-page SPA. Vanilla JS is indeed better than it was, but I found myself writing small JQ-like libraries and utilities to do tedious or even basic DOM manipulation, so I switched back to JQ and saved myself a lot of time and headaches. Compressed, minified JQ is also pretty small and is negligible in space consumption.
JQ is also used in frameworks like Bootstrap (although I think they’re trying to drop third-party dependencies like this since they tend to cause conflicts).
I have also used JQ in an Angular app where complex on-the-fly DOM manipulation just isn’t practical with standard tooling.
Hobbyists don’t want to learn every new framework. Someone can have a small business website for their activity and have been happy using jQuery since 2010.
Got it. Maintenance of Legacy websites is a big chunk of internet.
It’s refreshing to see jQuery 4
Wow. Great job.
hail to the king
Now what we need is realtime log forwarding from js to the llm.
still needs more jQuery
Now that's a name i've not heard in a long time...
[flagged]
I might argue the opposite. What would that have added to this release?
No love for $…?
jQuery is v4 now, but a lot of sites esp. wordpress still have 1.11 or 1.12 and only uses them to either doing modals(popover), show/hide(display), or ajax(fetch).
WordPress ships with 3.x and is already looking to update to 4
I was talking about a lot of sites in wordpress, not Wordpress themselves
If people haven't updated their sites in 10+ years, that's their problem. Has nothing to do with wordpress or jQuery
Even after migrating to ES modules, jQuery is still somewhat bloated. It is 27 kB (minified + gzipped) [0]. In comparison, Preact is only 4.7 kB [1].
[0]: https://bundlephobia.com/package/jquery@4.0.0
[1]: https://bundlephobia.com/package/preact@10.28.2
> 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.
I use Preact for a very lean build for a front-end that lives in a small embedded MCU flash ROM. Gziped the whole front-end is about 25KB, including SVG images baked-in to the preact gzip file. I'm very careful about the libraries I include and their impact on the overall payload size.
I had started with a simple front-end that was using jQuery to quickly prototype the device controls, but quickly exceeded my goal of keeping the front-end at under 40KB total gzipped. The problem is needing more than just jQuery, we also needed jQueryUI to help with the front-end, or build out similar complex components ourselves. And as soon as the jQuery code became non-trivial, it was clear that Preact made much more sense to use. Our payload is quite a bit smaller yhan the jQuery prototype was.
I do that when I need to make a simple SPA. Plain Vue plus a few tiny add-ons of my own.
Look at Deno + Fresh which is based on preact. You can do a lot with preact only
jQuery does a lot more though, and includes support older browsers.
Officially they state they only support 2 latest versions of chrome. But considering their support of IE11, that's actually a lot.
> includes support older browsers
Which is entirely the issue. Supporting a browser for the 10 users who will update jQuery in 2025 is insane.
Breaking backwards compatibility to turn 27kb into less because of "bloat" makes less sense to me.
It is definitely more than 10 users.
12