jQuery 4: I Can't Believe They Actually Did It

jQuery 4.0.0 shipped on January 17, 2026. I didn’t expect to write about jQuery in 2026.

The project has been around since 2006. Twenty years. Most JavaScript libraries don’t survive five. jQuery made it to version 4 after a decade of “you don’t need jQuery” blog posts.

What Changed

jQuery 4 drops IE10 and older browsers, along with legacy Edge. It does not drop IE11 from the full build. I originally collapsed those two facts into “no IE,” which was wrong.

Without legacy browser baggage, the team cut code that existed purely for compatibility:

• Old IE event and DOM workarounds
• Deprecated APIs such as jQuery.isArray() and jQuery.isFunction()
• Legacy Edge support
• Several undocumented signatures and compatibility paths listed in the official 4.0 upgrade guide

IE11 changes the build choice If your app still needs IE11, use the full build. The jQuery team recommends the full build or a Promise polyfill because the jQuery 4 slim build removes Deferreds and Callbacks.

The slim build also got slimmer. It removes Deferreds, Callbacks, and the queue module on top of AJAX and effects. Those removals are documented as slim-build breaking changes, not removals from jQuery 4 as a whole.

jQuery Admits the Browser Won

What slim removes and what replaces it:

The size difference:

jQuery 4.0.0 (gzipped)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Full  ████████████████████████████████████████ 27.6 KB
Slim  ████████████████████████████░░░░░░░░░░░░ 19.5 KB
                                    ↑
                                8.1 KB saved (29%)

The release notes put the difference at about 8KB gzipped. That does not decide performance by itself. For code that already uses fetch(), native Promises, and CSS transitions, it is 8KB of API surface the application does not call.

Check plugin dependencies The slim build keeps the part I still reach for in old interfaces: selectors, DOM manipulation, events, and traversal. Check the upgrade guide before assuming an older plugin only needs those pieces.

Slim or Full?

Use slim if you already use fetch() and Promises, jQuery only handles DOM and events, or bundle size matters (widgets, WordPress plugins, marketing pages).

Stick with full if you have a lot of $.ajax() code you’re not ready to refactor, or you need the animation queue for sequenced effects.

The Migration Path

jQuery 4 doesn’t force a rewrite. Migrate gradually:

1. Stop adding new $.ajax() calls. New code uses fetch().
2. Stop adding new jQuery animations. New code uses CSS transitions.
3. Replace $.Deferred() with native Promise when you touch old code.
4. Eventually swap jquery.min.js for jquery.slim.min.js.

-$.ajax({
-  url: '/api/users',
-  method: 'GET',
-  dataType: 'json'
-}).then(data => console.log(data));
+const response = await fetch('/api/users');
+if (!response.ok) throw new Error(`HTTP ${response.status}`);
+const data = await response.json();

Keep the HTTP status check when replacing AJAX. Keep if (!response.ok) before parsing the JSON. A fetch() promise can resolve for a 404 or 500 response; it doesn’t automatically turn an HTTP error into a rejected promise. The Fetch guide explains that distinction.

/* Old: jQuery fadeOut */
/* $('#box').fadeOut(300); */

/* New: CSS transition */
.box {
  opacity: 1;
  transition: opacity 0.3s ease;
}
.box.hidden {
  opacity: 0;
}

Vite’s ?url import emits an asset URL rather than bundling that file’s JavaScript dependency graph; this is a Vite boundary, not a feature of the slim build. If you’re loading jQuery via a script URL in an iframe or worker, test thoroughly.

Twenty Years Later

Twenty years after jQuery first shipped, the slim build draws a sensible boundary. Keep its DOM API where existing code still needs it. Let fetch() and CSS handle the work browsers absorbed years ago.

The import path is easy to misuse in Vite, so I documented the ?url distinction separately.