Back

jQuery 4

419 points10 hoursblog.jquery.com
blakewatson8 hours ago

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...

lioeters5 hours ago

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.

Sammi1 hour ago

I hear you saying that React raised the floor but also lowered the ceiling.

mb210057 minutes ago

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/) ;-)

Klaster_18 hours ago

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.

doix8 hours ago

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).

egeozcan4 hours ago

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...

hebelehubele4 hours ago

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.

Klaster_16 hours ago

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.

+1
doix6 hours ago
flomo6 hours ago

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.

gbalduzzi6 hours ago

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.

eloisius1 hour ago

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.

skizm38 minutes ago

Facebook is PHP ironically.

flomo5 hours ago

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.

sgt4 hours ago

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.

hsbauauvhabzb5 hours ago

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.

jraph4 hours ago

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...

hyperhello2 hours ago

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.

+1
jraph1 hour ago
adzm1 hour ago

The $ (and $$) selector functions live on in chrome/chromium devtools!

Sammi43 minutes ago

Very simple jquery implementation with all the easy apis:

  (function (global) {
    function $(selector, context = document) {
      let elements = [];

      if (typeof selector === "string") {
        elements = Array.from(context.querySelectorAll(selector));
      } else if (selector instanceof Element || selector === window || selector === document) {
        elements = [selector];
      } else if (selector instanceof NodeList || Array.isArray(selector)) {
        elements = Array.from(selector);
      } else if (typeof selector === "function") {
        // DOM ready
        if (document.readyState !== "loading") {
          selector();
        } else {
          document.addEventListener("DOMContentLoaded", selector);
        }
        return;
      }

      return new Dollar(elements);
    }

    class Dollar {
      constructor(elements) {
        this.elements = elements;
      }

      // Iterate
      each(callback) {
        this.elements.forEach((el, i) => callback.call(el, el, i));
        return this;
      }

      // Events
      on(event, handler, options) {
        return this.each(el => el.addEventListener(event, handler, options));
      }

      off(event, handler, options) {
        return this.each(el => el.removeEventListener(event, handler, options));
      }

      // Classes
      addClass(className) {
        return this.each(el => el.classList.add(...className.split(" ")));
      }

      removeClass(className) {
        return this.each(el => el.classList.remove(...className.split(" ")));
      }

      toggleClass(className) {
        return this.each(el => el.classList.toggle(className));
      }

      hasClass(className) {
        return this.elements[0]?.classList.contains(className) ?? false;
      }

      // Attributes
      attr(name, value) {
        if (value === undefined) {
          return this.elements[0]?.getAttribute(name);
        }
        return this.each(el => el.setAttribute(name, value));
      }

      removeAttr(name) {
        return this.each(el => el.removeAttribute(name));
      }

      // Content
      html(value) {
        if (value === undefined) {
          return this.elements[0]?.innerHTML;
        }
        return this.each(el => (el.innerHTML = value));
      }

      text(value) {
        if (value === undefined) {
          return this.elements[0]?.textContent;
        }
        return this.each(el => (el.textContent = value));
      }

      // DOM manipulation
      append(content) {
        return this.each(el => {
          if (content instanceof Element) {
            el.appendChild(content.cloneNode(true));
          } else {
            el.insertAdjacentHTML("beforeend", content);
          }
        });
      }

      remove() {
        return this.each(el => el.remove());
      }

      // Utilities
      get(index = 0) {
        return this.elements[index];
      }

      first() {
        return new Dollar(this.elements.slice(0, 1));
      }

      last() {
        return new Dollar(this.elements.slice(-1));
      }
    }

    global.$ = $;
  })(window);
egeozcan4 hours ago

jQuery but gets compiled out like svelte... Not a bad idea at all.

efskap3 hours ago

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.

egeozcan2 hours ago

Some things you build not because they are necessary, but because you can.

karim799 hours ago

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!

sieep2 hours ago

all these kids chasing the new frameworks...jQuery and .NET framework have always kept me fed!

b3ing9 hours ago

Nice to see it still around and updated. The sad part is I guess this means React will be around in 2060.

altern84 hours ago

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

lopatin4 hours ago

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.

gmac3 hours ago

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.

bossyTeacher2 hours ago

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.

mikeaskew48 hours ago

by 2060 React Native should be up to v0.93

b65e8bee43c2ed09 hours ago

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

2muchcoffeeman8 hours ago

Two Reacts!?

o_m4 hours ago

The main divide now is client side React versus Server Components usually with a node.js backend

exac8 hours ago

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).

+1
psnehanshu7 hours ago
atulvi6 hours ago

There was also react vr

tcoff918 hours ago

class components & function components.

afiori6 hours ago

That is the least interesting divide in the react community

ttoinou3 hours ago

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.

hypnot5 hours ago

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.

KellyCriterion4 hours ago

Curious:

Whats the current behemoth instead of JQ?

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

croes4 hours ago

Many things JQ introduced are browser native now.

bonzini1 hour ago

Or can be replaced by other technologies, like CSS animations that replace jQuery animation code with just addClass/removeClass.

rationably9 hours ago

Unbelievably, still supports IE 11 which is scheduled to be deprecated in jQuery 5.0

indolering5 hours ago

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

tartoran9 hours ago

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.

kstrauser6 hours ago

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.

sebazzz5 hours ago

“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.

kstrauser5 hours ago

Fair point.

croes4 hours ago

It’s rarely a horrid IT department but some special or legacy software without modern replacement

troupo5 hours ago

> 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

Strom4 hours ago

> 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.

+2
kstrauser5 hours ago
phinnaeus9 hours ago

Are those people/products upgrading jQuery though?

jbullock359 hours ago

Who is still stuck on IE 11---and why?

flomo6 hours ago

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.

jbullock354 hours ago

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

ejmatta9 hours ago

Some corporate machines still run XP. Why upgrade what works?

+1
ExpertAdvisor019 hours ago
ddtaylor9 hours ago

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.

simondotau5 hours ago

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

ulrischa7 hours ago

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

halapro7 hours ago

Yes, run jQuery 3.

Crazy to think that software running inside IE11 should use the latest version of a library.

chao-7 hours ago

I cannot express how much I admire the amount of effort jQuery puts into their upgrade tools.

senfiaj1 hour ago

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.

pocketarc2 hours ago

> 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.

wartijn_2 hours ago

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.

padjo1 hour ago

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!

jusonchan818 hours ago

The first time I truly enjoyed web development was when I got the hang of jQuery. Made everything so much simple and usable!

Joel_Mckay8 hours ago

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

admiralrohan2 hours ago

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?

temporallobe1 hour ago

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.

hotgeart1 hour ago

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.

gethly6 hours ago

jQuery was peak JavaScript.

Good times, I'm glad it is still around.

shevy-java6 hours ago

It is still used by many websites.

marticode5 hours ago

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.

lrvick5 hours ago

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?

simondotau5 hours ago

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.

jampekka5 hours ago

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

glemion435 hours ago

Until you have to upgrade it and it bites you

jampekka5 hours ago

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.

g947o2 hours ago

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.

NetOpWibby7 hours ago

I remember being scared of jQuery and then being scared of vanilla JS. My, how time flies.

Incredible it's still being maintained.

ulrischa6 hours ago

I still love the simplicity a ajax call can be done in Jquery

niek_pas5 hours ago

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

sethaurus51 minutes ago

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.

maxpert7 hours ago

jQuery is the last time I felt a library doing magic! Nothing has matched the feelings since then.

Minor49er7 hours ago

Not even modern vanilla JavaScript?

marticode5 hours ago

It's fairly close now but so much more verbose: ie document.getElementById('theID') vs $('#theID')

majewsky5 hours ago

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.

SahAssar44 minutes ago

    const $$ = (selector) => Array.from(document.querySelectorAll(selector))
is even nicer since then you can do things like

    $$('.myclass').map(e => stuff)
shevy-java6 hours ago

I am still using jQuery.

indolering7 hours ago

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!

johanyc4 hours ago

is there any reason to use jquery if you've never used it before

modarts3 hours ago

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

madduci7 hours 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.

nchmy48 minutes ago

What isn't available in vanilla js?

yread6 hours ago

Hmm maybe i can finally move on from 2.x

MarkdownConvert9 hours ago

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.

rtbruhan004 hours ago

It’s refreshing to see jQuery 4

AdrianB13 hours ago

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.

netbioserror9 hours ago

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.

NetOpWibby7 hours ago

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.

indolering5 hours ago

I really like that project! Why don't y'all hand it over to someone willing to do maintenance or at least archive it?

tpoacher7 hours ago

still needs more jQuery

tonijn9 hours ago

No love for $…?

gocsjess8 hours ago

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).

nchmy7 hours ago

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

thrownawaysz4 hours ago

The group photo is a perfect example of why DEI is important

pseudocomposer4 hours ago

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

maxloh9 hours ago

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

topspin6 hours ago

> 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.

ttoinou3 hours ago

Look at Deno + Fresh which is based on preact. You can do a lot with preact only

downsplat4 hours ago

I do that when I need to make a simple SPA. Plain Vue plus a few tiny add-ons of my own.

onion2k9 hours ago

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

halapro7 hours ago

> includes support older browsers

Which is entirely the issue. Supporting a browser for the 10 users who will update jQuery in 2025 is insane.

mejutoco6 hours ago

Breaking backwards compatibility to turn 27kb into less because of "bloat" makes less sense to me.

shevy-java6 hours ago

It is definitely more than 10 users.

ZeroAurora6 hours ago

Officially they state they only support 2 latest versions of chrome. But considering their support of IE11, that's actually a lot.