alt Hacker NewsAnother poster was pointing out that this is not necessarily what is meant by templates in the post. I can see the distinction, but not really sure it changes my view. Since the post is largely more javascript literals for dom objects, it is hard for me not to bring that back to the design implications? Literally comes back to "people love JSX" many times. Why? Because it lets them get things to the presentation layer that is their browser.
I took some time to dive into how extensive JavaScript has made the word template in their world. I confess it reads a bit excessive to me. More than a bit, really. Tagged templates, in particular, look like one of the biggest foot guns I've ever seen.
I took it to design because I don't know of any other real reason to template the DOM other than for design purposes. Indeed, reading on the linked proposal, this is to make reactive things on a page. And that will have to be married to a design at some point. Often the entire point of introducing names that are exported from data to a rendered document is for the presentation implications of it. Otherwise, you'd just output the data?
I'm not sure if I can contribute anything more here.
Tagged template literals, aka "template string literals" are yet another technology adjacent to JS and HTML using the word "template". But it doesn't have much to do with the submission.
It's just a fancy name for advanced string interpolation in JS, and has no inherent connection to DOM elements or fragments.
But it is used by some technologies such as styled-components and Lit (the web component library).
styled-components is probably also where the obfuscated CSS-in-JS class names in the bluesky markup originate.
There is also a `<template>` element that is used by ShadowDOM and web components.
But nothing of that is the essence of the post, these are just things that coincidentally use the word "template" (and, less coincidentally, the concept).
As far as I see, it is about the wish to standardize declarative data-binding to DOM trees.
Basically, a React-like API built into the browser, but less detached from native rendering algorithms.