I wrote a couple of blog posts on why we should add native templating to the DOM so we'd need fewer libraries.

The time is right for a DOM templating API: https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

What should a native DOM templating API look like?: https://justinfagnani.com/2025/06/30/what-should-a-dom-templ...

I would be very interested in an API similar to the plates[1] library, but with support for event bindings (instead of being just a one-off rendering of plain HTML). My first thought is that it might not be very maintainable, and at best might only be useful for small templates or templates that are heavy on microdata[2].

But there's just something about this type of binding that makes me want to give it a serious chance, at least once, before completely giving up on it.

[1]: https://github.com/flatiron/plates

[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Mic...

I skimmed through your blog posts, and the WICG proposal, and my main objection to it is making it depend on JavaScript.

There are plenty of ways HTML templating can be done already using JavaScript. The simplest approach of using tagged template literals, as you mention, doesn't even require external dependencies.

The problem with this approach is that it makes JavaScript a requirement for all but static sites, and those doing templating on the server. This shouldn't be the case.

The web as a platform should be flexible, and provide tools to build maintainable web sites and applications without forcing developers and users to depend on a specific runtime. JS should be an optional dependency, just like CSS is today. Even HTML should be optional, as Web Assembly gains traction, and the web browser becomes a software delivery platform.

Furthermore, making what should be a core HTML feature depend on JS is a colossal violation of separation of concerns. HTML modules should be a standalone feature, and we should be able to define a tree of HTML modules, import modules, reuse them, and so on. That should be the core groundwork on top of which templating is built on.

We've had Server-Side Includes and XSLT since the 90s, yet HTML templating should depend on JS? That's just silly.

Besides, there's a strong argument to be made for minimizing logic in templates or avoiding it altogether. Mustache and Handlebars have shown that this can work simply and elegantly. Whenever I see JS inside HTML attributes, I curse whoever came up with the idea. It's awful for legibility, maintainability, and plain sanity.

HTML can be a lot more capable without having to depend on JS. I think the discussion to drive this implementation forward would be well served by first principles thinking, instead of being inspired by modern web frameworks and JavaScript features.