Hacker News new | ask | show | jobs
jQuery 4.0 99% Complete (github.com)
46 points by okozzie 969 days ago
8 comments

Just leaving this here since people will wonder the relevance of jQuery today.

> jQuery is used by 94.5% of all the websites whose JavaScript library we know. This is 77.4% of all websites.

https://w3techs.com/technologies/details/js-jquery

How many of them are WordPress installations or sites running Bootstrap?
Modern WordPress themes do not use jQuery on the front-end.

Bootstrap does not require jQuery. Not sure if ever but not since 3.0 and were are at 5.0 at this point.

That’s a shocking number. I wonder how much of that is just duplicated instances of some standard template, Wordpress, whatnot.
Chances are you have "ed" installed on your currently used machine, but I doubt it was ever opened.

With that said, I'm quite surprised that jQuery is not abandoned, barely heard about it in the past decade or so. I suspect also that it is mostly part of boilerplate coming from other libraries and frameworks, and rarely intentional.

I write jquery almost every day for work (I work on wordpress sites)
The younglings don't seem to appreciate what a godsend jQuery was back in the day, it gave you a decent API that worked on all browsers, including IE6. HTMX nowadays is giving off a similar vibe, it gets you 95% there without modern JS insanity/complexity.
I can't speak to HTMX, but 1000% with jquery.
I use jQuery for JS for the same reason I use Twig for PHP.....it's way simpler to write functions to get things done.

People keep telling me to switch to ES6 but I'm never upgrading. Why would I? jQuery just feels like a good pair of jeans.

you can (should) use jQuery with ES6+
It has been a long time since I used jQuery. What exactly is the usecase today? Is it just syntactic sugar or has it changed significantly?
I think the main use case today is the dom traversal API. It makes operations like "add the 'error' class to all <input> elements in the form" simple:

    $('#some-form').find('input').addClass('error')
Obviously you can do this in vanilla JS, but it's more cumbersome so you'll probably end up rewriting your own less complete version of jquery. There is some value to using a well worn library with public documentation that other developers can find/extend instead of a home grown solution.

With that said, I wouldn't use it for a green field project. For sites that require lots of interactivity I would pick a modern front end framework that doesn't require this kind of manual dom traversal (probably phoenix/liveview).

Mostly off the top of my head:

    document.getElementById('some-form').getElementsByTagName('input').forEach(i => i.classList.add('error'))
It is a little more verbose but it isn't that much more cumbersome today.

That's also doing things "the right way" and not do-all selectors, but that option exists now, too:

    document.querySelectorAll('#some-form > input').forEach(i => i.classList.add('error'))
If you want to make it a little less verbose:

   const $ = document.querySelectorAll
   const addClass = (className) => (item) => item.classList.add(className)
   $('#some-form > input').forEach(addClass('error'))
However getElementById() can return null, thus that entire statement can error. In the old days you had to sprinkle your code with if checks when using the DOM API.
If you are requiring that element to be there for your script to work then that error is exactly what you want. Defensive programming is great and all, but sometimes your assumptions have to meet the road anyway and script errors are a perfect way to signal something went wrong (because that's what they are for).

Of course now we have additional defensive programming tools like `?.` and `??` operators.

It depends, if the page is very dynamic the element may or may not be there.

Point is that the DOM API version of the initial jQuery snippet are not equivalent. $() statement does a bit more than that.

This becomes obvious if the requirement are a bit more complex than the example, perhaps we want to chain more expression on at the end, then the DOM API version becomes more convoluted.

Love the syntax in the last example, you should make it into a library!
Maybe that npm package could get as famous as leftpad.
Is it that hard to:

    document.querySelectorAll("#some-form input").forEach(e => e.classList.add("error"));
No it's not
This won't throw an error if the form ID changes. Which is to be expected for working on collections. But I don't like this being the default, exactly because of cases like this.

Same thing of course applies to people who throw around the optional chaining operator without thinking to please TS.

Or would apply if one used a single selector here and document.querySelectorAll

The needless chaining here is a typical example of misleading jQuery code though. Looks as if it was there to prevent this issue.

What's wrong with

  for (const input of document.querySelectorAll('#some-form input') {
    input.classList.add('error');
  }
?

In fact, this has an even earlier baseline browser compatibility than

  NodeList.prototype.forEach
I can't really imagine willingly doing something nontrivial without a reactive framework these days. I'd be all for jQuery if I did want to do that though.
I almost always fall back to jq if it's loaded, vanilla js APIs are so annoying.
Is there some kind of summary available somewhere of what features are “unique” to jQuery (or at least significantly easier), and what features are now generally available as vanilla JS or CSS?

I’m not a JS developer and I just have a basic understanding of what jQuery is used for, so I’d be interested in seeing some kind of historical timeline, both to better understand why jQuery was originally created, and to understand what purpose it might fill today (legacy dependencies excluded).

Quite a feel of those seem like while you don't need jQuery (so the site is indeed actually named), it's still often easier. Doubly so when you consider that the non-jQuery methods don't always chain together.

Admittedly I'm usually using it in places where loading the extra library is not an issue, so if you're really going for slimline, then sure.

I've always thought that about this site. If they were trying to ease people off jQuery, showing the vanilla JS equivalent side by side is not going to have the desired impact!
This site perfectly shows why jQuery still rocks.
Perfect
Off the top of my head, jQuery has some unique selectors that aren't replicated in vanilla CSS, like :eq()
I wonder if the footprint got smaller or bigger.
It does not matter that much, relatively speaking. People include 1MB font libraries in their site without a care in the world, and force 1-2MB PNGs and JPEGs down the wire without caring. A few extra bytes in jQuery is nothing compared to that.
Yeah.

However, it does matter in interactive websites because if the js is light it'll load fast and execute fast and you'll have interactivity sooner. It may be the case that images can be loaded later or arent even visible on the home page. And fonts of course will be replaced once they are loaded and the defaults will be used while it loads so it's progressive in a way.

Interactive websites are slow because they are including 1 MB frontend frameworks... and use these bloated modern frameworks to set a class on an element.
Yes, I was just pointing out why having huge fonts/images isnt as big of a blocker as huge JS on today's JS heavy apps with "loading placeholders" and what not. The browser also does font replacement fairly smoothly.

Whether this whole bazaar is ideal or not is a separate issue :)

js and images are not directly comparable, you also need to consider that the js has to be parsed and evaluated. so it really depends: it may matter
Especially if it's served from a CDN, and thus likely already cached.

Then again, how many folks are using jquery these days? It might be more rare than I think.

> Especially if it's served from a CDN, and thus likely already cached.

Browsers no longer do cross-site resource caching. https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

Ah, shows how much I know about front-end stuff these days!
jQuery's footprint is 70KB for the minified version. There are thumbnail images that are bigger.
Love it how the homepage hasn't change in years.
It's very on brand with "Write less, do more".
Looking back jquery was probably the only frontend framework that wasn't obsolete in 18 months. There is also value in keeping things the same over a decade or more so the old farts can still be productive without having to relearn everything every couple of years.