←back to thread

218 points mdhb | 3 comments | | HN request time: 0.001s | source
Show context
lofaszvanitt ◴[] No.44392038[source]
Fisrt include jQuery as a whole into the base standard. That would help a lot.
replies(2): >>44392138 #>>44392216 #
edoceo ◴[] No.44392138[source]
I <3 jQuery but, no.
replies(1): >>44392161 #
lofaszvanitt ◴[] No.44392161[source]
What no? Why can't we have nice things, like concise, easy to remember, not overly elaborate syntax?
replies(1): >>44392327 #
ameliaquining ◴[] No.44392327[source]
jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?
replies(2): >>44392490 #>>44394246 #
eszed ◴[] No.44392490[source]
From bevr1337's comment, above:

> its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes

That's what I miss about it.

replies(1): >>44394267 #
jraph ◴[] No.44394267[source]
Doesn't querySelector(All) provide this?
replies(1): >>44394667 #
troupo ◴[] No.44394667[source]
Not entirely. There's a reason people do Array.from(querySelectorAll) to do more than just `forEach`
replies(1): >>44394983 #
jraph ◴[] No.44394983[source]
So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then?

Genuinely asking, I have no clue what's being alluded to without being clearly mentioned in this thread.

replies(1): >>44395686 #
troupo ◴[] No.44395686[source]
> So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then?

Array.from adds friction. The need to wrap querySelector in null checks adds friction. The fact that they are not composable in any way, shape, or form, with any DOM methods (and that DOM methods are not composable) adds friction.

jQuery was the fore-runner of fluid interface design. Nothing in the DOM before, then, or since ever thought about it. Even the new APIs are all the same 90s Java-style method calls with awkward conversions and workarounds to do anything useful.

That's why sites like "You don't need jQuery" read like bad parody: https://youmightnotneedjquery.com

E.g. what happens when it's not just one element?

   $(el).addClass(className);

   // vs.

   el.classList.add(className);

Or: why doesn't NodeList expose an array-like object, but provides an extremely anaemic interface that you always need to convert to array? [1]

   $(selector).filter(filterFn);

   // vs.

   [...document.querySelectorAll(selector)].filter(filterFn);

There's a reason most people avoid DOM APIs like the plague.

---

[1] This is the entirety of methods exposed on NodeList https://developer.mozilla.org/en-US/docs/Web/API/NodeList

Instance properties

- length

Instance methods

- entries() // returns an iterator

- forEach()

- item()

- keys()

- values()

replies(2): >>44396399 #>>44397879 #
WorldMaker ◴[] No.44397879[source]
You don't need Array.from if you are using `for (const x of document.querySelectorAll(selector) { }` loops anyway or have a library like IxJS handy.

ES2025 added map, filter, flatMap, reduce, forEach, and several other methods to all iterators (including NodeList directly, I believe, but definitely its entries(), keys(), values(), if not) [1]. It'll be a year or two at current pace before that is "widely accepted baseline" in browsers, but it's great progress on these sorts of complaints.

[1] https://2ality.com/2025/06/ecmascript-2025.html#iterator-hel...

replies(1): >>44398998 #
troupo ◴[] No.44398998[source]
> including NodeList directly, I believe,

I listed all public methods and properties of NodeList. It does have a forEach, so there's not much need for `for of`

As for iterator methods, I completely forgot about that :) Yeah, you can/will be able to use them on .entries()

replies(1): >>44399386 #
1. WorldMaker ◴[] No.44399386[source]
You missed [Symbol.iterator] as a public method. I prefer the aesthetics of for/of over forEach in most cases, but it's as much personal preference as anything.

I did briefly forget the distinction between Iterable (has [Symbol.iterator]) and Iterator (the thing [Symbol.iterator]() returns). You can use the Iterator helpers "directly" on the NodeList with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(someNodeList).map(…)`. There are advantages to that over `Array.from` but not many advantages over `someNodeList.entries().map(…)`.

(I partly forgot because I assumed MDN hadn't been updated with the new Iterator helpers, but of course it has [1], they are marked as "Baseline March 2025" [all browsers updated since March 2025 support them] and there is a lot of green in the browser compatibility tables. caniuse suggests Iterator.prototype.map is ~84% globally available.)

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

replies(1): >>44399444 #
2. troupo ◴[] No.44399444[source]
> with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(someNodeList).map(…)`

I always feel like clawing my eyes out with most of the DOM APIs, or workarounds for them :)

replies(1): >>44399821 #
3. WorldMaker ◴[] No.44399821[source]
[Symbol.iterator] is more the for/of API (protocol, more accurately) than a DOM API. It's an improvement today that the DOM APIs pick up niceties like direct [Symbol.iterator] in addition to Iterator methods like entries().

It's nice that there is syntax sugar for [Symbol.iterator] in both for/of and also the spread operator/deconstruction/rest operator (things like [...someNodeList] and const [item1, item2, ...rest] = nodeList).

In theory, the only missing piece is syntax sugar for Iterator.from() if you wanted to direct chain any iterable to the iterator helperrs. But in practice, that's also part of why the explicit iterator methods like entries() already exist and those are surprisingly well implemented (and have been for a while), including on NodeList.