The time is right for a DOM templating API

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.

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.