Back to Blog
jQuery 4.0: What Actually Changed (And Why It Matters)
After 10 years, jQuery 4.0 is here. Here's what changed, what broke, and what you need to know before upgrading—from someone who's been using jQuery since the early days.
Back
Frontend

Table of contents
jQuery 4.0: What Actually Changed (And Why It Matters)
Twenty years after John Resig introduced jQuery at BarCamp NYC, the team finally shipped jQuery 4.0.0. It's been almost a decade since the last major version, and honestly? The changes are mostly good news.
If you're still using jQuery in 2026, you probably have legacy code that works. The question isn't whether jQuery 4.0 is better—it is. The question is whether upgrading will break things.
Spoiler: probably not much. But there are some breaking changes worth understanding.
The Big Picture: What jQuery 4.0 Actually Does
jQuery 4.0 isn't a rewrite. It's a cleanup release. The team removed legacy code, dropped dead browser support, and modernized the build system. The result? A smaller, faster library that works better with modern tooling.
Most of your existing code will work. The breaking changes are mostly edge cases and deprecated APIs that should have been removed years ago.
1. Internet Explorer Support: Finally Gone
jQuery 4.0 drops support for IE 10 and older. IE 11 support remains for now, but the team plans to remove it in jQuery 5.0.
Why it matters:
- Removes thousands of lines of compatibility code
- Smaller bundle size (over 3KB gzipped reduction)
- Faster execution without IE workarounds
When it doesn't:
- If you still need IE 10 support, stick with jQuery 3.x
- Most modern projects won't care
The team also dropped support for Edge Legacy, very old iOS/Firefox/Android versions. If you're targeting modern browsers, this is pure upside.
2. Trusted Types and CSP Support
jQuery 4.0 adds proper Trusted Types support, which matters if you're using Content Security Policy with require-trusted-types-for.
Why it matters:
- Works with strict CSP policies
- Avoids CSP violations when manipulating HTML
- Better security posture for enterprise apps
The technical change:
Most async script requests now use <script> tags instead of XHR to avoid CSP errors. There are still a few XHR cases (like when using "headers" option), but the default behavior is CSP-friendly.
If you're not using CSP, you won't notice this. If you are, it's a welcome fix.
3. ES Modules: jQuery Goes Modern
The jQuery source code migrated from AMD to ES modules. This is a build-system change, but it has real implications.
Why it matters:
- Works with modern bundlers (Vite, esbuild, etc.) without RequireJS
- Can be imported directly as modules
- Compatible with
<script type="module">in browsers - Better tree-shaking potential
What changed:
jQuery switched from RequireJS to Rollup for packaging. The source is now published as ES modules on npm, making it compatible with modern JavaScript workflows.
If you're using a bundler, this is good news. If you're loading jQuery via CDN, nothing changes.
4. Deprecated APIs: The Cleanup
Several jQuery utility functions have been removed. These were deprecated for years and now have native browser equivalents.
Removed functions:
jQuery.isArray→ useArray.isArray()jQuery.parseJSON→ useJSON.parse()jQuery.trim→ useString.prototype.trim()jQuery.type,jQuery.now,jQuery.isNumeric,jQuery.isFunction,jQuery.isWindow,jQuery.camelCase,jQuery.nodeName,jQuery.cssNumber,jQuery.cssProps,jQuery.fx.interval
Why it matters:
- Forces migration to native APIs (which are faster)
- Reduces jQuery's surface area
- Smaller bundle size
The reality:
If you're using these, you'll need to update your code. But honestly? You should have migrated years ago. Native equivalents are faster and don't require jQuery.
5. Internal-Only Methods Removed
The jQuery prototype had some Array methods (push, sort, splice) that were never meant for public use. They're gone now.
Why it matters:
- Cleaner API surface
- Less confusion about what's public vs internal
If you were using them:
Replace $elems.push(elem) with [].push.call($elems, elem). But if you were using these, you were probably doing something unusual anyway.
6. Focus Event Order: Now Follows W3C Spec
This is a subtle but important change. Browsers finally agreed on focus event order, and jQuery 4.0 follows the W3C specification instead of jQuery's old custom order.
The new order (W3C spec):
- blur
- focusout
- focus
- focusin
jQuery's old order:
focusout, blur, focusin, focus
Why it matters:
- Consistent behavior across all modern browsers
- Matches native browser behavior
- Less confusion when debugging focus-related code
The catch:
If you have code that depends on jQuery's old event order, it will break. But this is rare—most code doesn't rely on specific event ordering.
7. Slim Build: Even Smaller
The slim build got smaller by removing Deferreds and Callbacks (now around 19.5KB gzipped).
Why it matters:
- Smaller bundle for projects that don't need async utilities
- Native Promises are available in all supported browsers (except IE11)
When to use slim:
If you're not using $.Deferred() or $.Callbacks(), the slim build is perfect. If you need IE11 support, use the main build or add a Promise polyfill.
Most modern code can use native Promises anyway, so this is a good trade-off.
What About Breaking Changes?
The jQuery team says most users can upgrade with minimal changes. That's probably true, but here's what to watch for:
Definitely breaking:
- Code using removed utility functions (
jQuery.isArray, etc.) - Code depending on jQuery's old focus event order
- Code using internal Array methods on jQuery objects
- Apps that need IE 10 or older
Probably fine:
- Standard DOM manipulation
- Event handling
- AJAX requests
- Animations
- Most common jQuery patterns
The upgrade path:
jQuery Migrate plugin is available to help identify issues. Use it during testing, then remove it once everything works.
Should You Upgrade?
Upgrade if:
- You're targeting modern browsers
- You want smaller bundle sizes
- You're using modern build tools
- You want CSP compliance
Stay on 3.x if:
- You need IE 10 support
- You're in maintenance mode
- You can't test thoroughly
- The upgrade risk isn't worth it
For most projects, upgrading makes sense. The bundle size reduction alone is worth it, and the modern tooling support helps if you're using bundlers.
Final Thoughts
jQuery 4.0 is what jQuery should have been years ago. It's smaller, faster, and works better with modern JavaScript tooling. The breaking changes are mostly cleanup—removing APIs that should have been deprecated long ago.
The library isn't dead. It's just finally modern.
If you're still using jQuery in 2026, you probably have a good reason. Legacy codebases, WordPress plugins, or projects where jQuery is deeply embedded. jQuery 4.0 makes those projects better without forcing a complete rewrite.
That's the real win here.
References
- jQuery 4.0.0 Release Announcement - Official jQuery blog post
- jQuery 4.0.0 on npm - npm package
- jQuery CDN - CDN links for jQuery 4.0.0
Comments
No comments yet
Loading comments...