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