> For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`.

Actually, .children is the child elements; .childNodes is all the children (including comments and text as well as elements).

> Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`?

I’m not sure why they want with .classList instead of .classes, but I expect .className is a part of the history. If redesigning it from scratch and still retaining the functionality of .children, I’d rename it .childElements. Certainly not .childList.

And of course, the reasons for most of this stuff is the history. Some of the web’s APIs have aged well; others haven’t.

jQuery is nice for small widgets (if you don't mind loading another library), but as soon as you start to make truly reactive content, it falls on its face. A reactive framework like Vue essentially makes your javascript variables control what is rendered implicitly based on their value, instead of explicitly calling a function.

Since the ViewModel binds the variables to the controls, hundreds of lines of jQuery required to update controls literally vanishes. It blew my mind once I understood what reactivity meant in real life. I rewrote a fairly large site in Vue and the JS LOC shrank by nearly two orders of magnitude (of course, a lot of that was due to the previous webdevs problems).

Now that I'm used to Vue, I view jQuery more like a skin disease, some kind of rash that makes everything ugly and swollen.

You can just assign document.QuerySelector and document.QuerySelectorAll to $ and $$ yourself.

You can, and some JS consoles provide this for convenience if those vars are unused, but jQuery really shines with method chaining. That’s what I miss the most from it. You could manipulate the DOM in incredible ways in “one line” of code.

FYI chaining and a handful of the most common operations can be implemented in just a few lines of code: https://gist.github.com/paulirish/12fb951a8b893a454b32

(Although I reach for the "cash" library instead of this or jQuery when I need something jQuery like)

Depends what you want to do, but I've kind of come around because I feel like if what I want to do is so complicated that I can't easily do it in vanilla JS, it's also complicated enough that I don't necessarily want to do it by manual DOM manipulation. Changes the calculation if you have to support older browsers and such though.

I've used jQuery in the past, but switched to native js/ts.

I found that while jQuery offers some nice synthetic sugar, it's mostly geared towards web frontend and actual logic continue to have to reside in native. I'd rather just know one thing (but I'm a backend programmer that only does js/ts for fun, so there's that).

Mostly geared toward frontend? It’s been a while since I used JQuery but I thought it is specifically a frontend library.

Maybe they mean UI?

> but natively is the mouthful of `document.querySelectorAll('selector')`

I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find it's too easy to re-use a word in different context, especially if it's different people doing the coding vs CSS.

Selecting descendants or sibling elements? Selecting based on tag and class? Selecting elements with a given attribute present or matching a particular value? Selecting elements with classes starting or ending with a given string? Selecting elements without children? Selecting elements that aren't any of the above.

The question should be the other way around: Why is there `getElementsByClassName` when you can do `querySelectorAll('.myClass')`? Why have `getElementById` when we have `querySelectorAll('#myId')`? Why have `getElementsByTagName` when we have `querySelectorAll('tagName')`?

Apart from the historical reasons both `getElementsByClassName` and especially `getElementById` are optimised - the latter being a simple lookup - which I'm not sure `querySelectorAll` is able to take advantage of.

You’d pay the cost of parsing every time, but otherwise I’d expect SelectorAll to directly depend on getElementBy.. as relevant

I use it all the time for bookmarklets and userscripts when I want to customize a page that I can't modify directly. Vendor site showing too many out of stock items? querySelectorAll('div.out-of-stock') and wipe them all out. Filter options not good enough? querySelectorAll('div.price').forEach( /* delete products between x and y prices */ ).

class, id, and tag name are only a small subset of the things you can get with a css query, and you can't combine them with anything when you use the dedicated querySelector methods.

document.querySelectorAll("[data-my-attr=something]")

document.querySelectorAll(".foo > [data-my-attr=something]")

etc.

getElementsByClassName and getElementsByTagName return live HTMLCollection objects that update when the DOM changes (or rather get re-computed when you access their contents following a DOM change). Depending on what you do with them, you may end up with worse performance compared to the NodeLists returned by querySelectorAll.

It’s slower but, assuming you have control over page content, I’d think the answer is probably pseudo selectors or sibling selectors. The more complex stuff really.

Of course if that’s a need the page needs work but, not everything is “fixable” in time limited business cases.