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:

  JQUERY:
  $(el).toggle();

  IE8+:
  function toggle(el) {
    if (el.style.display == 'none') {
      el.style.display = '';
    } else {
      el.style.display = 'none';
    }
  }

Gotta love that "modern" triple attribute repetition.

From: https://youmightnotneedjquery.com/#toggle

A more modern solution would be to use classList.toggle() or toggleAttribute(hidden).

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

> Gotta love that "modern" triple attribute repetition.

You can golf it down a bit:

    el.style.display=el.style.display == 'none' ? '' : 'none';

Even though I can appreciate the elegance of your solution, I'd prefer the former for clarity.

Surely

    el.style.display = el.style.display ? 'none' : ''

(after toggling we've already obliterated any possible third value for it anyway, doesn't seem significant)

Of course. Because that's infinitely better than:

  $(el).toggle();

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.

Edit: https://caniuse.com/?search=classlist.toggle and click Usage Relative.

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

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.

> The argument for querySelector / querySelectorAll calls is literally mimicked from John Resig's grounbreaking API design

Absolutely not.

Absolutely yes.

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:

https://johnresig.com/blog/thoughts-on-queryselectorall/

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.

<https://twitter.com/simonw/status/1536129600232665088>

<https://www.slideshare.net/jeresig/history-of-jquery>

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.

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.

> lazy and ignorant

Go fuck yourself.

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.

https://news.ycombinator.com/newsguidelines.html

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.

https://news.ycombinator.com/newsguidelines.html

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.

>For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one.

Just like leftpad.

Instead of needing to import leftpad you have the missing standard js lib

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

[1] https://docs.python.org/3/library/stdtypes.html#str.ljust

[2] https://docs.python.org/3/library/stdtypes.html#str.rjust

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.

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

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.

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.

What's changed is the billion dollar tech industry invested in convincing people that JQuery is a dead and obsolete technology.

For some reason, JQuery is the exception to the general rule of seeing a mature, battle-tested library as a sign of quality.

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

That was part of the problem that jQuery was solving.

Another part was the abysmal API that Javascript (and mostly still today) offers to work with the DOM.

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.