Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The time is right for a DOM templating API

justinfagnani.com

Post reply on HN
Print view View original

191–200 of 256 posts

Re: The time is right for a DOM templating API

#191

Post by taeric »

moritzwarhier wrote: post #183
taeric wrote: post #143

Earlier quoted context omitted.

I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own. Basically, my assertion used to be to draw out…

But flex layout is fundamentally different from tables, I guess you meant grid with that reference? It's not that every website uses CSS grid for layout. Coincidentally, I took a look at the DOM+CSS of a bluesky post just a few days ago (very weird coincidence, since that was the first time I opned bluesky for months), and it did use old-school tricks like centering using CSS transforms, presumably because renders a…

I did mean grid, there.

And don't get me wrong, I don't necessarily want everything absolute positioned. I just find it amusing when people try to get a badge or some such on something and then herculean efforts they will go through to get that badge exactly where they want it.

So, with bluesky, the amount of markup that goes into the footer menu of each post would be what I'm looking at. Tools were clearly used to get styles such as "css-g5y9jx" and this isn't the worst examples I've seen. But I am curious on why so many nested divs seem to be needed all of the time.

I am not clear what you mean by canvas-like approach? I think folks should still use elements. Just fewer of them, all told.

Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements. They largely don't even think of sections of their template as parent/child relationships. They have a visual thing and want it filled in with whatever data.

Re: The time is right for a DOM templating API

#192

Post by taeric »

9rx wrote: post #181
taeric wrote: post #179

Earlier quoted context omitted.

You didn't share a templating language, though? You shared an example of a formatting/templating string, but didn't even indicate what level of format string it supported. Such that I don't know if you are sharing C's printf, bash's printf, PHP's... I can presume you don't intend to include CL's FORMAT. Even if I do have a softspot for it, myself.

> You shared an example of a formatting/templating string Which is, you guessed it, a language! Okay, yeah, I didn't dive in so deep as to provide a formal specification for the language, or whatever it is you were hoping for, but if you really want to take this to silly town, I'm going to tell you that what you saw is the only valid input for this language and only specify that, so, maybe, unless you are having fun…

My question to you, then, is if you think you contributed anything at all to this? Because, yeah, nothing there.

Re: The time is right for a DOM templating API

#194

Post by DangitBobby »

taeric wrote: post #144
chii wrote: post #106

Earlier quoted context omitted.

> People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well the web has the requirement that the 'document' look good no matter what device size/dimension, orientation, and/or capability. In regular apps (say, a windows app), you don't have this requirement. In mobile apps, there's a standardized set of sizes. Only on web do we have both!

Not really? People impose the idea that they can make this work. Yet no sites looked good on the Nintendo DS browser, and people were largely ok with that. Few sites look genuinely good on phones. People are largely ok with that.

The Nintendo DS browser was not good enough to use as a daily driver. My phone, on the other hand, I spend more time browsing on that than I do my computer. Some sites aren't great on it, but the vast majority are fine (reader mode will get you through 99% of the rest). I'd argue most sites don't "look good" on any device. It's really not that hard these days to make a site work on mobile, the navbar often is the most challenging part of it.

Re: The time is right for a DOM templating API

#195

Post by codedokode »

The web platform is over bloated. The proper solution would be a minimum set of APIs and set of reusable by many sites JS/Wasm libraries.

For example, most of Web Audio (thing like filters and oscillators except for actually sending audio to audio card) could be implemented in Wasm making a browser simpler and not allowing to use it for fingerprinting. Also, base64 encoding/decoding, URL handling function, most of canvas code etc. Imagine how less work for browser developer it would be.

Re: The time is right for a DOM templating API

#196

Post by WorldMaker »

troupo wrote: post #188
WorldMaker wrote: post #177

Earlier quoted context omitted.

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 bas…

> 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()

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...

Re: The time is right for a DOM templating API

#197

Post by troupo »

WorldMaker wrote: post #196
troupo wrote: post #188

Earlier quoted context omitted.

> 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()

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(som…

> 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 :)

Re: The time is right for a DOM templating API

#198

Post by 9rx »

taeric wrote: post #192
9rx wrote: post #181

Earlier quoted context omitted.

> You shared an example of a formatting/templating string Which is, you guessed it, a language! Okay, yeah, I didn't dive in so deep as to provide a formal specification for the language, or whatever it is you were hoping for, but if you really want to take this to silly town, I'm going to tell you that what you saw is the only valid input for this language and only specify that, so, maybe, unless you are having fun…

My question to you, then, is if you think you contributed anything at all to this? Because, yeah, nothing there.

Yes, it contributed to my enjoyment. I mean, that is all that can be contributed, fundamentally, so...

Re: The time is right for a DOM templating API

#199

Post by llcooliovice »

> We've explored the reactivity landscape. While early DOM templating proposals didn't include updating, userland systems have thoroughly explored the landscape by now, and discovered good mental models and better and worse implementation approaches. I think we can now zero-in on a system that combines the best features from the different approaches.

AFAIK Ryan Carniato/Solid JS is still exploring what’s possible with signals. I don’t think userland exploration of this space has entirely finished, and further innovation may be possible.

Re: The time is right for a DOM templating API

#200

Post by nchmy »

nine_k wrote: post #175
nchmy wrote: post #133

Earlier quoted context omitted.

Nah. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://news.ycombinator.com/item?id=43971164

React appeared in 2013, Svelte, in 2016. Three years is a lot. What comes next can see and avoid some pitfalls of earlier designs.

1. I'm referring to the comment that the DOM is slow/bad. It is not. Moreover, VDOM is ON TOP OF the DOM.

2. We're currently living in 2025. React (and SPAs) is not even slightly necessary.

Post reply on HN