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

51–60 of 256 posts

Re: The time is right for a DOM templating API

#51

Post by sethaurus »

hsn915 wrote: post #31

What we need is not templating. What we need is a native implementation of a virtual dom. More specifically, a native implementation of the "patch" function: patch(target_dom_node, virtual_dom) Where `virtual_dom` is just a plain-data description of the DOM. Most of the "slowness" of the DOM come from its requirement to be a 90's era Java style object hierarchy. Don't call it "templating". Just call it "virtual dom".…

Other than quibbling over the word "template", how does that differ from what TFA is describing?

Re: The time is right for a DOM templating API

#52

Post by hyfgfh »

pier25 wrote: post #17

The web really needs native templating, reactivity, and data binding. I can't even begin to imagine how much CPU and bandwidth is wasted with billions of users downloading, parsing, and executing something like React.

That's alright now LLM and crypto make this waste seem minuscule

Re: The time is right for a DOM templating API

#53

Post by mosdl »

Nextgrid wrote: post #37
sabellito wrote: post #24

Earlier quoted context omitted.

My company, me as a solo dev, back in 2003-04 built a "single page app" using XUL and iframes. Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window. XUL was beastly back then though.

> Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window. Out of curiosity, what does that app do to convince people to jump through such hoops? Would you mind sending a link to it?

Quite common, lots of old software that is custom written lives on, be it java apps, old vb stuff, etc

Re: The time is right for a DOM templating API

#54

Post by quotemstr »

shermantanktop wrote: post #25

A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues. This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example. If a proposal like this…

> A basic lesson we've learned over and over is that API/ABIs aren't final

I dunno --- getElementById has been stable for, what, 25 years? "There's no such thing as a stable API" is something said by people unable or unwilling to create interfaces that last. It's a statement of personal resignation, not cosmic impossibility. There are tons of counterexamples.

Application needs, like other needs, are infinite. You satisfy these needs by adding new APIs, not breaking working ones.

Re: The time is right for a DOM templating API

#55

Post by leeoniya »

d--b wrote: post #49

The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible. I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one. But these abstractions have a huge mental / implementation cost. The problem, as with most engineering things is a tradeoff problem. The r…

> The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.

there are multiple frameworks now that do fine-grained diffing without relying on signals, proxies, or any other reactive primitives. they basically have the top-down react model but much faster and without the weird concepts like hooks and manual/wasteful dependency arrays.

my favorite one is ivi-js: https://github.com/localvoid/ivi

it's just 8% slower than the fastest / ugliest / imperative / unmaintainable vanilla js you can eventually arrive at if all you care about is winning benchmarks.

https://krausest.github.io/js-framework-benchmark/2025/table...

Re: The time is right for a DOM templating API

#56

Post by dleeftink »

shermantanktop wrote: post #25

A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues. This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example. If a proposal like this…

> spends most of its useful life being the old thing that people are trying to work around

But in the process, the base functionality has been propped up another level.

Incremental updates aren't worthwhile just because of userland requirements that will always discover new gaps, use-cases and blindspots.

Re: The time is right for a DOM templating API

#57

Post by btown »

shermantanktop wrote: post #25

A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues. This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example. If a proposal like this…

It's also the case that every feature in web standards means extra code that needs to be painstakingly maintained, and extra code that anyone trying to create a standards-compliant browser must implement. I want to see projects like https://servo.org/ actually have a chance to catch up over time, not always be chasing an expanding scope.

I want the web platform to have every possible capability that native platforms have (subject to privacy and sandboxing constraints, of course). And I want the developer experience of web developers to be incredible.

But these need to be balanced against the consequences of added complexity. And in this case, does native templating really improve developer experience? I'm not convinced the benefits outweigh the costs.

Re: The time is right for a DOM templating API

#58

Post by wavemode »

I would argue that the proliferation of frontend frameworks is evidence is that we -don't- know what the optimal abstraction is for building frontend applications. We're all still trying to figure that out.

Just look at what happened with Web Components. It didn't take over or become the foundation of everyone's software. It just became yet another competitor [0].

I wish the standards committees would focus their efforts on improving JavaScript the language. That has a much greater and more lasting return on investment.

[0]: https://xkcd.com/927/

Re: The time is right for a DOM templating API

#60

Post by eclipticplane »

wahern wrote: post #39
taeric wrote: post #34

Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…

> Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT. I think where XSLT fell…

It's been a long number of years, but XUL (Mozilla/Firefox's UI layer) combined with XSLT was an incredible stack to build entire applications.
Post reply on HN