One website that almost always gets mentioned when people talk about jQuery today is "You might not need jQuery" (https://youmightnotneedjquery.com/).
That site is the best ad for jQuery I've ever seen. For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one.
And that's after almost 20 years, and I don't know how many billions of dollars invested into advancing JavaScript.
This is incredible and such a great ad for jQuery. It's almost as if the creator(s) built that site ironically. So many examples are way clearer and easier in jQuery, like this one:
> It's almost as if the creator(s) built that site ironically.
No, the site's advice is simply more narrow and fine-grained than a blunt 'never use jquery'. From the front page:
> jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.
> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement.
This seems eminently reasonable to me. For a website, adding a jquery dependency costs little and you get much nicer, more maintainable code.
But for a library, every transitive dependency introduces the possibility of future version conflicts for applications that depend on it. And at the same time, library code shouldn't need to change and grow nearly as much as application code.
So library authors should strongly consider forsaking mere convenience for the sake of reducing dependency baggage. This isn't even JS-specific advice, it applies to most ecosystems.
Toggle was a bit of a pitfall because the developer had to keep track of all the possible states prior to that line. It's easy to drop in as a function when needed in simple scripting (expanding faq sections, etc.)
IE8 is a bit of a straw man. We've dropped IE entirely when testing unless there's significant (1%+) usage for particular clients, but even the NHS in the UK has dropped IE11.
Plus, the jQuery example also accepts any selector for `el`, including ones that select multiple elements.
The `toggle(el)` function only accepts a single element that you've already selected (e.g: via `document.getElementById("foo")`). You'd need to at least add a call to `querySelectorAll(...).foreach(toggle)`, if you wanted to preserve that piece functionality (which you admittedly don't always want).
It's the jQuery API design. I often find myself creating functions like this one:
export function $(query, root=document) { ... }
jQuery acted as a role model for standard web committees. The argument for querySelector / querySelectorAll calls is literally mimicked from John Resig's groundbreaking API design.
jQuery selector engine was developed before the official Selector API, which ended up being almost exactly the same. Except for a few exceptions which John wasn't too sure about when they asked for feedback:
I don't know what you think that link shows (I don't know what John thought it showed, either—it's a classic "talking to one's own head, instead of who you're trying to communicate with" situation, and David Baron's confusion on the mailing list at the time is understandable).
To reiterate:
> The argument for querySelector / querySelectorAll calls is literally mimicked from John Resig's grounbreaking API design
No, it wasn't. "The argument for querySelector / querySelectorAll calls" is literally ... CSS's selector language, which predates jQuery by about a decade. And the idea to make a library function to match against selectors was conceived of and implemented by Simon Willison years before jQuery was released, spawning lots of copycats. jQuery was literally named jQuery because writing a library to do this was the hotness at the time and one such library Resig had used was called cssQuery.
(jQuery does do a lot more than just match CSS selectors, but what that involves is not something jQuery has in common with querySelector—it's nowhere near "almost exactly the same". The result of a jQuery call has a weird, jQuery-specific shape. (It's not an element node). If Simon's getElementsBySelector did what jQuery did, Resig wouldn't have written jQuery.)
This is a matter of public record, and to state or suggest otherwise is worse than just being wrong. It misleads and confuses people.
Using CSS to select elements within the browser arguably only became popular because of jQuery, (and Prototype, Mojo, etc.). The browser inbuilt suggestion at the time was to programmatically navigate the DOM, or maybe use XPath. Proposing CSS selectors as a browser API before it became dominant in the wild via alternatives would have got a "why do we need another option?" response.
So you couldn't get away with lazy and ignorant two word answer and it forced you to write quality one :)
One would argue whether we'd have querySelector if jQuery wasn't as popular. We may have an inspiration chain here... but thanks for pointing out to prior art.
Please don't cross into personal attack, regardless of how wrong someone is or you feel they are. It's not what this site is for, and destroys what it is for.
You're mixed up in your understanding of how burden of proof works and who has it here. Spoiler alert: it's the burden of the person making the claim—not the one dismissing it.
Please don't cross into personal attack, regardless of how provocative someone is being or you feel they are. It's not what this site is for, and destroys what it is for.
Yesterday I was checking HN from 10years±2weeks ago and guess what the top posts were... "Why you need jQuery" and "You might not need jQuery". I'm too young to know about those days but I guess not much has changed in relation to people's attitude towards jQuery.
The problem jQuery was solving was to provide a usable abstraction over an inconsistent platform for core functionality like event handling and DOM manipulation.
The point of the last decade and a half of standards work was to eliminate that problem, and it has at least moved it from "core web functionality" to more complicated areas like bluetooth, 3d rendering and audio, which jQuery's goals do not include handling.
Is it urgent to remove jQuery from projects? Not really. And it's good the jQuery team maintain the project for that reason. Certainly some projects have gotten performance gains out of removing it, but part of the work they've done in 3.x and now 4.x is arguably jQuery removing stuff internally and replacing them with the now reliable browser APIs.
But on the other hand, is there a great argument for including jQuery in new projects? This is also a "not really".
It was initially sold as a way to fix browser incompatibilities, but I still use it because there are really nice plugins like select2. I really don't see the point in SPA apps for the most part. Fair enough if you have a heavily interactive frontend, but I can build an app in Django with a bit of JQuery and end up with around half the code compared to adding in React.
That site message is "don't import all of jquery just to use the $ global and one or two specific functions".
It's a very fine message and the site contents spread it quite well. But if you actually want to use jquery instead of just some function you got from a reference, by all means, use it, it's a very nice library.
Much of the billions are used to make JavaScript worse. E.g. ESM is a byzantine mess compared to CJS, and the ceremony and bondage of TypeScript is dramatically increasing busywork.
It isn't missing. Javascript was created to serve a specific purpose, which didn't include left-padding text in a terminal. Most language I'm aware of wouldn't have that in their standard lib.
If you want Javascript to act as a drop-in replacement for C++ or Java or some other general programming language (which Javascript was never intended to be) don't act as if needing to write libraries to cover that missing functionality is a problem with the language. You're using the wrong tool for the wrong job.
> Most language I'm aware of wouldn't have that in their standard lib.
Python has str.ljust [1] (and str.rjust [2]):
> Return the string left justified in a string of length width. Padding is done using the specified fillchar (default is an ASCII space). The original string is returned if width is less than or equal to len(s).
Ruby and PHP both have string padding functions. So does Swift. (edit: and as Macha points out, C and any language with printf functionality, like Perl.) It’s not that uncommon.
(I was going to joke that TRS-80 BASIC had it circa 1979, but it turns out that it would be a two-step operation: Python’s str.ljust(40) would become LEFT$(STRING$(40, " "),40) .)
C has it in their standard library, basically forever. See the list of specifiers to printf. C! If it fits into the C standard library, it's not bloating the Javascript standard library.
That site is the best ad for jQuery I've ever seen. For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one.
And that's after almost 20 years, and I don't know how many billions of dollars invested into advancing JavaScript.