If you've been building for the web long enough, you probably have at least one jQuery story. Maybe it was the first time you made a dropdown behave properly across browsers. Maybe it was the moment you realized you could stop writing ten lines of DOM code just to do one simple thing. Either way, jQuery has been part of the internet's "muscle memory" for a long time.
Now, jQuery 4.0.0 has officially landed, and it's the first major jQuery release in nearly a decade. The timing is intentionally sentimental too: jQuery was first introduced on January 14, 2006, and this release arrives as part of the project's 20th anniversary moment.
But this isn't jQuery trying to "be cool again." It's more like jQuery doing what mature projects should do: modernize, slim down, reduce risk, and make upgrades as painless as possible.
What This Release Actually Means
jQuery 4 is less about shiny new features and more about getting the foundation aligned with modern web reality.
The core theme is: remove old baggage without breaking the world.
The jQuery team's message is basically that most projects should be able to upgrade with minimal changes, and they point developers to an official upgrade guide and the jQuery Migrate plugin to help catch compatibility issues.
If you're maintaining a site that still depends on jQuery (and plenty do), this is a reassuring kind of release. It's not a reinvention. It's a well-planned "let's keep this solid for the next era" update.
The Big Shift: Dropping More Legacy Browser Weight
One of the loudest changes is browser support.
jQuery 4 removes support for Internet Explorer 10 and older, plus a handful of other aging platforms like Edge Legacy and older mobile browser baselines (such as iOS versions outside the last few). IE11 still makes the cut for now, but the team has already signaled that IE11 support is expected to be dropped in jQuery 5.
That's a big deal because so much of jQuery's historical value was "I'll smooth out browser weirdness for you." By raising the baseline, the library can delete a lot of code that existed purely to handle browsers most teams have stopped targeting.
And yes, the internet reacted exactly how you'd expect: plenty of people pointed out that modern vanilla JavaScript has improved so much that a lot of the change log is basically… removal.
Modern Packaging: ES Modules Move jQuery Back Into Today's Tooling
Another very practical upgrade: jQuery's source has moved from AMD to ES modules. That matters because ES modules are what modern build tools and workflows expect.
Alongside that, the project has shifted its packaging approach from RequireJS to Rollup. The result is a library that plays more nicely with modern bundlers, module imports, and "script type=module" usage.
If your workflow already lives in ES modules world, this is jQuery catching up to how you build today instead of forcing you into older patterns.
Security and CSP: Trusted Types Support Is a Quiet Win
One of the most important upgrades isn't flashy at all, but it's very "2026 web app" in spirit: Trusted Types support.
jQuery 4 adds support for Trusted Types so that HTML wrapped in TrustedHTML can be used with jQuery DOM manipulation methods without tripping strict Content Security Policy rules (specifically when sites use CSP directives like "require-trusted-types-for").
They've also adjusted how async script requests are handled (leaning toward script tags rather than inline scripts) to reduce CSP-related headaches.
If you've ever tightened CSP and then watched half your legacy code start complaining, you already know why this matters.
Cleaning House: Deprecated APIs Finally Exit the Building
A major part of "jQuery 4" is removing APIs that were already deprecated and now feel unnecessary because browsers have had clean native equivalents for years.
Functions like jQuery.isArray, jQuery.parseJSON, jQuery.trim, and jQuery.now are gone, because native alternatives such as Array.isArray(), JSON.parse(), String.prototype.trim(), and Date.now() have long been standard. That removal alone saves a few kilobytes of compressed code.
This is jQuery saying: "If the platform already does it well, we don't need to keep carrying it."
The Slim Build Gets Slimmer
The "slim build" story continues too. In jQuery 4, it's been reduced further (roughly around the 19.5 KB gzipped range reported in coverage) by removing Deferreds and Callbacks from the slim build, leaning on native Promises instead.
That's a pretty clear signal of where jQuery sees the modern baseline: promises everywhere (except the lingering IE11 reality, which is part of why full builds still matter for some teams).
So… Why Would Anyone Still Use jQuery?
This is the part that always turns into a debate online, and the most honest answer is: it depends what you're building, and what you already have.
For greenfield apps, many developers won't reach for jQuery first. Frameworks and modern DOM APIs cover most needs, and component-driven architecture is the default in many teams now.
But jQuery still has a strong "boring is good" value proposition in real-world situations, especially when you're dealing with:
Maintaining or extending large existing codebases that already use jQuery, where rewriting isn't realistic.
Small interactive behaviors on mostly server-rendered pages, where adding a whole framework is overkill.
Progressive enhancement workflows, where you want the page to work fine without JavaScript, and then improve when JS is available.
Situations where predictable DOM manipulation and a well-known plugin ecosystem are still useful.
That "stable and predictable" identity comes up a lot in community reactions: jQuery isn't trendy, but it's reliable, readable, and familiar to a huge number of developers.
How to Get It
jQuery 4.0.0 is available via the official CDN and on npm. If you're using npm:
npm install jquery@4.0.0
That part is easy. The real work is just being smart about the upgrade path: use the upgrade guide, use jQuery Migrate, and test the parts of your UI that touch older jQuery behaviors.
Final Thoughts
jQuery 4 feels like the kind of release you get when a project knows exactly what it is.
It's not trying to out-framework the frameworks. It's not pretending the web hasn't changed. Instead, it's trimming legacy weight, modernizing the internals, improving security compatibility, and keeping the upgrade path realistic for the millions of sites that still depend on it.
In a web ecosystem where tools come and go at warp speed, there's something oddly refreshing about a release whose main achievement is: "We cleaned up, we got safer, we got leaner, and we're still going to be here when you need us."
Comments