I guess I should specify, not available as easy as jQuery. Technically anything that jQuery does can, obviously, be done natively, but I remember there were some things that were much much much easier to do in jQuery than natively. Some of those easy patterns have been adopted into native, but surely not everything.
Array.from(document.querySelectorAll('.foo')).forEach(el => el.style.display = 'none');
document.querySelectorAll('.age').forEach(el => el.style.display = 'none')
I fail to see the superiority of that approach after more than a decade.
To me, the success of React and the likes has more to do with team dynamics, hiring, etc.
Essentially it's declarative programming, you declare your UI should look this way when the state is this, and that way when the state is that.
It's much easier to reason about than when you have a thousand random functions that can change the UI, often in ways that break each other.
I can separate concerns instead of multiple functions changing the same UI, but I can’t guarantee that everyone else will.
The conventions that React provides sidesteps the need for discipline and that I find useful.
Doesn’t mean that the approach in itself is better, IMO. and if you work alone, it’s clearly way too much trouble for little gain.
I don't know why querySelectorAll() doesn't just return an array.
some-selector .foo {
display: none;
}It is easy as hell. What's there to not like? I don't care to be called names or being old fashioned.
I also don't care about "right" tooling for frontend. As far as it works, it is robust and it is going to be around for many years, I am fine with it.
The foundation lists jQuery under its Impact Projects which are described as:
> Impact projects are on a sustaining cycle of development, maintenance, and long-term support. These projects are used commonly in enterprise production environments and have large, well-established project communities.
> ...
> They receive ongoing financial and marketing support from the Foundation, and are expected to cross-promote the foundation along with their activities.
This seems to me like they expect to continue to support jQuery for the foreseeable future.
The CSS selector bit was always the strongest portion to me. Getting that into your project allows you to get more work and involvement in the system from your 'just a frontend person' people, and reluctant backend people working on the UI.
Add to this the ability to apply CSS selectors to your ancestors, which has been lacking from DOM for far, far too long.
But the last leg of that stool is the list comprehension semantics. Being able to implement "select all" or "clear all checkboxes" in one line of code. The only problem with this functionality is that it fails silently on a bad or out-of-date selector, and I think that was a mistake, but one that is hard to fix in retrospect without creating another library with different defaults. I think by default that such a call should fail, with an override for that 1 in 20 case where you just don't care.
I'd also like to see either fewer frameworks or more frameworks that have thin veneers over common libraries, like jQuery. People underestimate the psychological safety people get from feeling that they could leave a job or ecosystem whenever they want. We behave as if stuckness leads to complacency, but your best coworkers see complacency as a warning, and will choose half-considered actions (like jumping ship) as a viable alternative to the status quo. People who get unstuck can become your enemy instead of just an ex-user as well, feeling they need to 'rescue' others from your dirty clutches.
The following is more stream of consciousness than something I've thought about, so someone who has thought about it longer can probably clever out a good answer. In later versions it's tried harder not to get itself into reflow loops, but since I'm not an active user anymore, I don't know if that's so much a standalone feature as it is fixing bugs in the abstraction. There's probably other ways to fix such problems too, something more like zip() semantics, where you take a selector, run all of the get() operations, look at the answers, and only then mutate the list. Perhaps there's a two argument API in there, or maybe a fluent interface would flow better.
document.querySelectorAll('[name^="starts-with-this"]') document.querySelectorAll('[name*="contains-this"]')