Like a collapsible section that's lightly animated.

I worry too about people not considering accessibility.

A lot of my bugs day to day is not being able to tab into things like hover menus or being able to activate buttons because someone forgot to consider correct event callbacks.

Maybe it's different now, but using a jQuery makes it more likely the code will cover cases like that.

This isn't a complaint you can level at the gov.uk team. They're obsessed with accessibility. Gov.uk is probably the best example of a well-designed, well-built, completely accessible website on the whole internet.

There's some CSS transition stuff you can add to that to make it lightly animated: https://css-tricks.com/how-to-animate-the-details-element/

Yeah, jQuery might make some things easier, but when possible, using native HTML elements makes things even easier,

https://code-boxx.com/expand-collapse-div-css-only/

Vanilla js for similar things just looks like someone has waved the ugly stick at it.

There are sound arguments against jQuery but the "you can just use vanilla" is the least convincing.

Even GOV.UK, an incredibly lean website by today's standards, only noticed a 10% difference in their benchmarks.

Cue all the people going on about big O for parts of the code that are indistinguishable from noise in actual benchmarks.

I wish we could have standardized in the Linq-like API of jQuery.

The primary use case for it has been cross browser compatibility plus a bit of sugar. The former is _gone_ and the latter is easily replaced with a few lines of JS. Then there is an ecosystem of libraries and components around it. Many of them have ditched jQuery or have provided an API that doesn't require it.

I think if you strip out the AJAX support it can get extremely tiny.

To compare, just roughly:

For roughly the same size you can get declarative/reactive rendering with React, or an optimized FP standard library with ClojureScript, or data driven visualizations with d3 (roughly 2x the size).

For a tenth of the size you can get stuff like htmx, or a json validation library (avj), or like someone said Preact (React alternative).

But for jQuery, you're paying that for basically nothing the browser APIs don't already provide. It was a godsend 10y ago, but with legacy browsers finally fading out, the last one being ie11, you really don't _need_ it anymore.

It provides a clean API for manipulating the DOM, as this site demonstrates (which is ironic): https://youmightnotneedjquery.com/

Personally, for simple sites, I aim for vanilla JS but use jQuery (cash, actually) where it makes sense - such as working on collections of elements.

Steve Gibson's site is an example:

https://www.grc.com/default.htm

   const $ = document.querySelector.bind(document);

The point seems to be that you don't even need that any more, so just get rid of it. Not sure why people latch onto cruft so much and defend its continued use.

On the performance side they cite 10 percent improvement, which doesn't sound like much to a lot of people. But remember that performance gains/regressions get compounded. Maybe there are 8 things that each eat 10 percent - you either start improving somewhere or you just refuse to even try. If I could improve 10 percent while removing a dependency I'd be all over that.

A characteristic of communities with lots of people that do not have a theoretical background. JS, PHP, jQuery, some parts of Ruby/Python -- they defend it with their life, and I argue it's because the rest of the world looks very scary to them.

I think this really seems to stem from a "I'm only used to jQuery, anything else is a big mental effort to learn and I'd rather stick with what I know".

I get it. Vanilla JS, if you're not used to it, is scary. But if you're advocating for jQuery "for simple interactions", and assuming it's simpler than vanilla JS, at some point you should ask yourself if you're just letting your skills stagnate, and staying stuck in the past. You owe it to yourself to update your skillset. If you decide you still need jQuery (e.g. maybe you need a plugin/library that requires jQuery), then fine. But at least you'll be making an informed decision, not a FUD-driven one.

Handcrafting JavaScript applications without jQuery is possible, the real question though is: is it convenient if you like and find productive using jQuery? Here's a fact: you can always remove jQuery later when the product is mature and standards understood and there is time budget for it.

I think a lot of people owe a lot of thanks to jquery.

But in 2022 vanilla javascript is all you really need.

    // jquery
    $(selector).on('click', fn)
     
    // vanilla js
    document.querySelectorAll(selector).forEach(el => 
      el.addEventListener('click', fn)
    )

Having said that, for the sake of 25kb - if you use more than a handful of features you might as well just include it.

It takes only 1 minute to write a wrapper, so you will write one, and I'll write one, and your dog will write one.

But most of the time, you find you need another wrapper, and then another, and the next thing you know you have most of jQuery, just not as uniform or as well tested.

I've seen this with database ORMs also.

your npm's dependencies authors cat will write a small wrapper and wont know about yours.

It's even easier if you copy paste from here: https://anguscroll.com/just/

At the very least there are some jQuery alternatives that are modular, smaller, and have less backwards compatibility like iirc zepto.

document.addEventListener('click', function(e){ var t = e.target;

  if(t.closest('.foo') && t.nodeName.toLowerCase() === 'button'){
     e.preventDefault();
     // do stuff here
  }
  else if(t.closest('.bar') && t.nodeName.toLowerCase() === 'a' && t.classList.contains('here')){
     e.preventDefault();
     // do smth else here
  }

one listener to rule them all...?

elegant enough and once you get used to it...

.closest can be pollyfilled too..