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

171–180 of 256 posts

Re: The time is right for a DOM templating API

#171

Post by 9rx »

taeric wrote: post #170
9rx wrote: post #164

Earlier quoted context omitted.

That which improves upon previous solutions. I have no idea what substack and bluesky are, but I'll take that to suggest that someone used templating to create a mess. While that is no doubt true — someone can create a mess out of anything — would the same person have avoided the mess if the templating wasn't there? It is just ergonomics, after all, not some fundamentally different idea.

substack and bluesky are just newer sites. I don't even think they are bad. Just I question the volume of markup that they use to layout stuff. Knowing that that is the standard. Do you have examples that are good?

At the time, this was good:

   printf("%d", 10);
It might not hold up to today's standards, but "good" isn't a constant.

Re: The time is right for a DOM templating API

#172

Post by WorldMaker »

agos wrote: post #121
CharlieDigital wrote: post #48

Earlier quoted context omitted.

Except React.....

if (when?) Signals become a standard, React will be in a tight corner if they decide to ignore them

Not really? `useSignal` is just another hook React needs as a replacement/augment for `useState` and maybe `useEffect`. Signals aren't that special. Arguably that's part of why a lot of people like Signals as a proposal.

(I'm still of the sort that thinks Signals are just worse Observables, so it's not a proposal I'm particularly thrilled about, but were it to be adopted Signals are easy to use in Observable contexts as well, they are just uglier half-implemented BehaviorSubjects, though maybe with a few extra lint rules to prefer Observable behaviors over Signal ones.)

Re: The time is right for a DOM templating API

#173

Post by taeric »

9rx wrote: post #171
taeric wrote: post #170

Earlier quoted context omitted.

substack and bluesky are just newer sites. I don't even think they are bad. Just I question the volume of markup that they use to layout stuff. Knowing that that is the standard. Do you have examples that are good?

At the time, this was good: printf("%d", 10); It might not hold up to today's standards, but "good" isn't a constant.

So, no? You don't have any examples by which to demonstrate what a good templating language is?

You seem to have gone on a tangent that "good" is a general topic in my question. I meant do we have specifically good examples of templates. Surely if we know what good templating syntax is, we can share examples of it? Even if you can't describe it directly.

Re: The time is right for a DOM templating API

#174

Post by 9rx »

taeric wrote: post #173
9rx wrote: post #171

Earlier quoted context omitted.

At the time, this was good: printf("%d", 10); It might not hold up to today's standards, but "good" isn't a constant.

So, no? You don't have any examples by which to demonstrate what a good templating language is? You seem to have gone on a tangent that "good" is a general topic in my question. I meant do we have specifically good examples of templates. Surely if we know what good templating syntax is, we can share examples of it? Even if you can't describe it directly.

I provided a good template language, at least given what was good at the time it was introduced. As good is necessarily a moving target, one can never really satisfy your request as by the time the submission has round-tripped it is quite possible that what is good has already been redefined.

So, yes, I understand you are trying to call attention to my 'loosey-goosey' usage earlier. But I am saying that when I said "good", it was relative to the temporal position it found itself in.

Re: The time is right for a DOM templating API

#175

Post by nine_k »

nchmy wrote: post #133
nine_k wrote: post #88

Earlier quoted context omitted.

If you valued your sanity when developing complex Web UIs, React was a lifesaver. DOM sucks though, it's slow, it's heavyweight, it lacks transactions. We're stuck with it, and frameworks like React have to do the DOM diffing + patching thing, explicitly, in JS.

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.

Re: The time is right for a DOM templating API

#176

Post by taeric »

9rx wrote: post #174
taeric wrote: post #173

Earlier quoted context omitted.

So, no? You don't have any examples by which to demonstrate what a good templating language is? You seem to have gone on a tangent that "good" is a general topic in my question. I meant do we have specifically good examples of templates. Surely if we know what good templating syntax is, we can share examples of it? Even if you can't describe it directly.

I provided a good template language, at least given what was good at the time it was introduced. As good is necessarily a moving target, one can never really satisfy your request as by the time the submission has round-tripped it is quite possible that what is good has already been redefined. So, yes, I understand you are trying to call attention to my 'loosey-goosey' usage earlier. But I am saying that when I said "…

Then take my question as, "then what is a good templating example today?"

Dodging the obvious question in favor of discussing if we can make progress... feels less than good faith.

Re: The time is right for a DOM templating API

#177

Post by WorldMaker »

troupo wrote: post #115
jraph wrote: post #102

Earlier quoted context omitted.

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.

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

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

Re: The time is right for a DOM templating API

#178

Post by 9rx »

taeric wrote: post #176
9rx wrote: post #174

Earlier quoted context omitted.

I provided a good template language, at least given what was good at the time it was introduced. As good is necessarily a moving target, one can never really satisfy your request as by the time the submission has round-tripped it is quite possible that what is good has already been redefined. So, yes, I understand you are trying to call attention to my 'loosey-goosey' usage earlier. But I am saying that when I said "…

Then take my question as, "then what is a good templating example today?" Dodging the obvious question in favor of discussing if we can make progress... feels less than good faith.

I still consider the templating language I shared before, even at the time of this comment, to be good.

But, as recognized earlier, others may find it doesn't hold up to today's standards. "Good" is not only not a constant, but is also subjective. Do I really have to explain the entire universe here? Man.

Re: The time is right for a DOM templating API

#179

Post by taeric »

9rx wrote: post #178
taeric wrote: post #176

Earlier quoted context omitted.

Then take my question as, "then what is a good templating example today?" Dodging the obvious question in favor of discussing if we can make progress... feels less than good faith.

I still consider the templating language I shared before, even at the time of this comment, to be good. But, as recognized earlier, others may find it doesn't hold up to today's standards. "Good" is not only not a constant, but is also subjective. Do I really have to explain the entire universe here? Man.

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.

Re: The time is right for a DOM templating API

#180

Post by leeoniya »

localvoid wrote: post #157
troupo wrote: post #152

Earlier quoted context omitted.

In the context of "let's create a native templating syntax for the browser" those differences between JSX and tagged templates don't matter. You still need something that the browser needs to parse and understand, you still need something for libs/frameworks to handle/understand/compile to. My feeling is that tagged templates would actually be a worse fit in this scenario because now you would have to distinguish bet…

If I understand it correctly, the main argument in favor of tagged templates is that it doesn't require any changes to the js engine and that is why it will be way much easier to push forward. Browser implementation should be quite straightforward and it will be possible to implement a semi-efficient polyfill. Personally, I don't think that it will have any significant impact, everyone will continue using React,Vue,S…

that's a better distillation :)
Post reply on HN