[simion314]

I wish JS would get all the nice jQuery features, like all the css selectors jQuery has, like a nice feature would be when you retive an HtmlElementCollection to be able to apply some transformation to all elements without having to write a for, or make use Array.from and then use forEach.

But I agree I would not use jQuery in new project and when possible I would replace jQuery in existing code too.

[Someone1234]

That's what everyone keeps missing. Can vanilla do what jQuery can? Of course, and that has always been true. What jQuery (and similar) offer is quality of life stuff, vanilla has never even tried to offer.

This is still an ecosystem without a standard library and with no consistent design style/layout. It is janky and bad. It being "less bad than it used to be" isn't the shiny endorsement that everyone thinks it is.

[nikanj]

jQuery is implemented in vanilla JS, thus logically all of it’s features can be done vanilla JS

[0xFF0123]

That's a bit like saying everyone should code in assembly. The argument isn't whether it's possible, but whether it's easier / more efficient.

[nikanj]

I guess I should have added more meat to my comment:

It’s frustrating when people reject a good tool like jQuery, with the argument that the same functionality can be achieved with just vanilla JS.

[adamisom]

That is generally true and not really specific to jquery

[acdha]

> to be able to apply some transformation to all elements without having to write a for, or make use Array.from and then use forEach.

This has worked for many years. I typically add a shorthand $ for the QSA part and on projects where I used to support IE11 you could add Array.from there but I haven’t bothered since IE was deprecated. jQuery does more but some of those things had performance impacts which were worth thinking about and the combo of QSA and fetch took care about about 90% of my projects.

document.querySelectorAll("div").forEach(i => i.innerText = "test")

[megous]

You can extend HtmlElementCollection prototype with any methods you like. (it's NodeList, btw, what's returned from querySelectorAll)

[strbean]

My understanding is that mutating built in prototypes is very bad. Not just for interop reasons, but because doing so really hinders many optimizations javascript engines perform.

[cogman10]

Adding methods to prototypes is effectively free. The only time mutating a builtin prototype has negative consequences is when you replace a builtin function with your own thing. All javascript engines (that I'm aware of) JIT at the method level so there's not really a performance impact modifying a prototype.

[strbean]

Ah, I think this is what I was thinking of: https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_...

It seems this only pertains specifically to overwriting the __proto__ of an existing object (the is the prototype of other things).

[simion314]

There is an issue you need to be aware , be careful if you hide the fact that this collection is "live". I mean this part from the docs

>An HTMLCollection in the HTML DOM is live; it is automatically updated when the underlying document is changed. For this reason it is a good idea to make a copy (eg. using Array.from) to iterate over if adding, moving, or removing nodes.

So you need something that will also be efficient and correct, not a 5 minutes implementation.

[megous]

Same issue applies if you mutate array you're iterating over during iteration using those Array.prototype functions. This is just a general issue with any data structure.