Posted by mdhb 7 days ago
> 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.
Genuinely asking, I have no clue what's being alluded to without being clearly mentioned in this thread.
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);
$(selector).filter(filterFn);
// vs.
[...document.querySelectorAll(selector)].filter(filterFn);
---
[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()
But to me, these are minor inconveniences and habits. A thin wrapper can get you there easily if you care enough. I personally dislike this array/element confusion that jQuery adds.
But that's more and more friction. A wrapper here, a wrapper there, and if here, a try/catch there. At one point you are reinventing significant chunks of jQuery
- a plugin system
- its custom selector parser (because it had it before querySelector and is not totally compatible with it)
- its abstraction to iron out browser differences (old IE vs standard, notably) that's not relevant anymore
- its own custom (DOM) event management
- its implementation of methods that are now standard (ajax & trim for instance)
I recognize that the DOM API could be better, and comes with friction. Back then, ironing out the browser differences and its selector feature were killer features of jQuery. Today, I do not think the quirks of the DOM API warrant importing a library like jQuery.
¹ but indeed, very lightweight compared to modern frameworks like Angular, React and Vue, with all the ecosystem which comes with each of them (react-router, redux, etc).
If you are going to use many features of jQuery, then it makes sense to use it, but if it's only a matter of writing one or a with wrappers, then jQuery is overkill.
I don't have a strong opinion on the proposal described in the article.
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...
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()
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...
I always feel like clawing my eyes out with most of the DOM APIs, or workarounds for them :)
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.
In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course).
There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ be slightly more performant from using a lower level of templating, as an optimization, but I'd certainly prefer that to be abstracted away and buried deep inside React, rather than ever having to think about it myself, at the JSX layer.
Someone can let me know if React is already leveraging this for browsers that support it, I didn't research that.
1. Making it possible to do something like <template src="..."> and being able to load them from an external source
2. Making them "dynamic"
3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.
#3 is a tricky one syntactically because HTML needs to be used by mere mortals and JS is a programming language used by us gods, so unifying all three would br tricky, but again I agree with you that would be awesome. Maybe some flavor of LISP would be both "powerful like a language" and "easy like a document".
I've done that, requires no build step/npm/whatever. It was posted on HN for discussion a week ago: https://github.com/lelanthran/ZjsComponent
I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.
Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).