[p-e-w]

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.

[Finbarr]

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

[piaste]

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

[extra88]

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

[mschuster91]

> Gotta love that "modern" triple attribute repetition.

You can golf it down a bit:

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

[OJFord]

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)

[anakaine]

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

[Finbarr]

Of course. Because that's infinitely better than:

  $(el).toggle();

[1123581321]

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

[frereubu]

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.

[fwip]

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

[tipiirai]

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.

[admaiora]

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.

[krapp]

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.

[Macha]

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

[collyw]

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.

[gunapologist99]

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.

[marcosdumay]

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.

[jampekka]

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.

[LamaOfRuin]

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

Just like leftpad.

[ipaddr]

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

[krapp]

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.

[selcuka]

> 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

[chipotle_coyote]

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

[Macha]

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.