The time is right for a DOM templating API
44 comments
·June 26, 2025taeric
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 inevitable that someone will want to template something that isn't well formed, but can combine into a well formed thing. And then you are stuck trying to find how to do it. (Or correlated entities on a page that are linked, but not on the same tree, as it were. Think "label" and "for" as an easy example in plain markup.)
If I could wave my magic wand, what we need is fewer attempts to make templates all fit in with the rube goldberg that is the standard document layout for markup. People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well. Sure, you might have to do math to get things to fit, but why do we feel that is something that we have to force the machine to do again and again and again on the same data?
wahern
> 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 over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.
wpm
I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.
pier25
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.
nwienert
React isn’t templating though.
nitwit005
If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed.
There has been long running complaints about how many UI frameworks there are, and how often they change. It's settled down some, but I don't expect that situation to change for a long while.
segphault
Instead of adopting JSX, I would really like the syntax for this to be more like the way Kotlin uses receivers and builders to provide a generalized syntax for DSLs that happens to be good for describing component hierarchies. It would be broadly useful far beyond just HTML templating, it would also be great for expressing configurations and all kinds of other things.
The actual semantics for templating and data binding could just be a set of standard functions that use those syntactic feature, much like what you see in Jetpack Compose.
BiteCode_dev
You don't even need much: loops, conditionals on attributes, and conditionals on nodes.
In fact, we could have that cross-language.
hsn915
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)
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". Everyone knows what that means.
Sophistifunk
When are we done adding everything into the browser API?
wewewedxfgdf
Hopefully never.
Unless you loved IE6 of course, which was when Microsoft declared the web browser to be 'complete'.
rs186
The author was a core contributor of Google's Lit project: https://github.com/lit/lit
mosdl
I miss mozilla's XUL language (and XBL!), those were awesome.
latortuga
Seems like a comment comes up about XUL every few years and I can't help but be sniped by it. A xulrunner app was my first job out of college in '08, good memories, fun dev environment!
sabellito
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.
Nextgrid
> 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?
sabellito
It's a full management app for recruiting companies.
There are still 3 companies that use it (since 2008), so their employees don't have a choice really. The app does a lot, so to stop using it the companies would need to hire and migrate to 3-4 other services. I reckon SAP and the kind could do everything as well, but these companies are too small for that.
There isn't a website or anything anymore for me to show, and I haven't been involved in it for over 10 years.
watersb
there-is-only-XUL
ericyd
> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element.
I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?
krebby
I think this is referring to the fact that React uses synthetic event listeners - it's cheaper to bind an event listener once at the root and do your own element matching than it is to continuously bind and unbind listeners.
https://react.dev/reference/react-dom/components/common#reac...
bevr1337
> React doesn't provide a way to explicitly bind to properties and events of DOM elements
We can nitpick this point because react has had a ref API for at least 5 years now. Given a ref, all DOM API are available. For events, SyntheticEvent will refer to a native event if it exists.
The SyntheticEvent abstracts vendor discrepancy. Under the hood, react can apply some optimization too.
https://legacy.reactjs.org/docs/events.html https://react.dev/reference/react-dom/components/common#reac...
MrJohz
The synthetic event also adds its own abstractions though. For example, the `onChange` handler in React behaves very differently to the native DOM `change` event.
PaulHoule
What about
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
?
The next two documents are part of a set that I made which did DOM-based templating on the back end in Java
https://ontology2.com/the-book/html5-the-official-document-l...
https://ontology2.com/the-book/source-code-transclusion-in-h...
one trouble is that systems that work at the DOM tree level are an order or two magnitudes slower than string-based templating systems. Hypothetically you could do some interesting things like hygenic macros and merge together arbitrary documents, rewriting the CSS classes and such. But by and large people find string-based templates to be good enough and don't way to pay the price for something more expensive.
WorldMaker
Currently <slot>s only have automatic behavior when attaching a <template> to the Shadow DOM to a node with existing "Light" DOM children, which mostly only happens with Web Components (and for now Web Components require JS).
So it is not yet a full, generic templating solution.
Also, this article goes on at length about how the templating needs to be "reactive" and not just "builds a DOM tree", and <slot> doesn't do that yet at all, even in the automatic behavior scenarios, it's a one time "merge".
Kicking the can along the road of the complexity of "reactive" components is a large part of how we've got the (quite basic) <template> and <slot> tags that we got, and I think why the article is still currently impractical. There needs to be more agreement on what "reactive" means. The article mentions the signals proposal, and that's one possibility that a lot of frameworks are pushing for right now, but it's still a process before browsers agree to support something like that, and something like that is a dependency before agreeing on what a "reactive" template language can be/how it would work out of the box.
bravesoul2
Depends where the platform boundary is for Web. As much as we hate JS fatigues and so many frameworks, choice is good. Maybe if the browser can make it easy for these frameworks to be performant and integrate more deeply (not part of the JS bundle but more like a deeper JS 'plugin' with bonus of sometimes having a cache hit from another site) we could just carry on using React et. al.
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 succeeds, it lives a time in the sun, but then spends most of its useful life being the old thing that people are trying to work around, just like the DOM API, just like ECMA versions, just like old browsers, just like every other useful bit of tech that is part of the system but can't be touched.
Is it possible to think about entropy, extension and backcompat as primary use cases?