jQuery 4 (opens in new tab)

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.

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.

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.

Haha, I remember that very clearly. Remember this?:

https://stackoverflow.com/questions/2826791/am-i-using-too-m...

I mean… jQuery and .NET (6+) can still feed you very well :D

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.

Until you have to upgrade it and it bites you

Are you Carson?

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

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:

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

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

const $ = document.querySelectorAll

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.

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.

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

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.

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

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.

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.

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.

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.

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.

Two Reacts!?

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.

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.

Are those people/products upgrading jQuery though?

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

Yes, run jQuery 3.

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

Prototype

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

Yes, okay, some can. Vue, petite-vue, Alpine, ...

Many things JQ introduced are browser native now.

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

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.

Yes, my default to go now is Django + Tailwind with HTMX and celery for background tasks. That alone took me far away.

I think it's probably a matter of things being easier: show()/hide() or simple animations versus futzing with style properties and CSS animations.

Got it. Maintenance of Legacy websites is a big chunk of internet.

I was talking about a lot of sites in wordpress, not Wordpress themselves

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

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.