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?
shermantanktop · 43m ago
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?
pier25 · 1h ago
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 · 24m ago
React isn’t templating though.
hsn915 · 24m ago
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". Everyone knows what that means.
segphault · 1h ago
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 · 1h ago
You don't even need much: loops, conditionals on attributes, and conditionals on nodes.
> 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 · 13m ago
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.
I miss mozilla's XUL language (and XBL!), those were awesome.
latortuga · 1h ago
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 · 49m ago
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.
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 · 3h ago
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 · 1h ago
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.
As mentioned, the DOM API is a stinker. Does this address that root issue?
I'd love to see something that builds on the work of hyperscript and HAST. They are great models of the DOM. It would be exciting if a template language were syntax sugar.
JSX is easy to reason about because its elements are 1:1 with a single, uniform function call. That feature means JSX is always optional. Sometimes it is even more verbose or less-performant to use JSX than a hyperscript API like specifying optional properties. I think errors and call stacks are clearer than during string interpolation, but that's possibly BS.
Web components offer limited data binding and the hyperscript approach has clear control flow. The templates seem to be a source of confusion in the GH discussions.
There is still something special and pleasant about jquery because its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes. After a beer or two I'm convinced emacs and org mode approaches are worth emulating in the web.
Great article and linked discussions. Thanks for sharing.
jongjong · 39m ago
Yes, it's weird that Browsers were so fast to ship CSP rules to prevent XSS attacks by limiting the use of inline scripts but so slow to ship a templating mechanism which would largely solve the problem.
It's like creating regulations which require a specific solution before that solution exists.
insin · 2h ago
We'd need a good API for UI components to go with it
wg0 · 3h ago
Need a DOM snapshot API too.
lofaszvanitt · 1h ago
Fisrt include jQuery as a whole into the base standard. That would help a lot.
bravesoul2 · 1h ago
Out of FE for a whole but isn't that done to a great extent.
edoceo · 1h ago
I <3 jQuery but, no.
lofaszvanitt · 1h ago
What no? Why can't we have nice things, like concise, easy to remember, not overly elaborate syntax?
ameliaquining · 53m ago
jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?
eszed · 26m ago
From bevr1337's comment, above:
> its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes
That's what I miss about it.
quantadev · 2h ago
Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way.
In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course).
There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ be slightly more performant from using a lower level of templating, as an optimization, but I'd certainly prefer that to be abstracted away and buried deep inside React, rather than ever having to think about it myself, at the JSX layer.
Someone can let me know if React is already leveraging this for browsers that support it, I didn't research that.
rictic · 1h ago
The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.
nwienert · 17m ago
I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right.
The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.
Hoping I missed something because otherwise my take is that this idea is sort of misguided at least in part.
In fact I don’t see any reason a browser level “here’s new DOM you diff and apply it” wouldn’t be a huge win for React, and React is more popular than basically every other framework combined. So to dismiss solving the biggest use case reeks of “I want my solution to be better so I’ll just conveniently drop the bigger problem for something that makes my solution better”.
I don’t see any reason why a generic diff solution or some low level improvements to updating trees of DOM in batches wouldn’t be doable. Would be a huge win and could even eventually build up into a template type thing on top of it.
To build the template thing first is the classic mistake of the web API authors over the last decade - jumping to high make some huge high level concept a standard before they let the exosystem even shake out, missing the abstraction, and everyone paying dearly for it (see web components).
Gualdrapo · 1h ago
"If I could wave my magic wand..." at least 2 of 3 of the changes I'd made about the way frontend web is developed, would be about `<template>`s:
1. Making it possible to do something like <template src="..."> and being able to load them from an external source
2. Making them "dynamic"
3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.
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?
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?
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.
More specifically, a native implementation of the "patch" function:
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". Everyone knows what that means.
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.
In fact, we could have that cross-language.
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?
https://react.dev/reference/react-dom/components/common#reac...
XUL was beastly back then though.
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.
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.
I'd love to see something that builds on the work of hyperscript and HAST. They are great models of the DOM. It would be exciting if a template language were syntax sugar.
JSX is easy to reason about because its elements are 1:1 with a single, uniform function call. That feature means JSX is always optional. Sometimes it is even more verbose or less-performant to use JSX than a hyperscript API like specifying optional properties. I think errors and call stacks are clearer than during string interpolation, but that's possibly BS.
Web components offer limited data binding and the hyperscript approach has clear control flow. The templates seem to be a source of confusion in the GH discussions.
There is still something special and pleasant about jquery because its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes. After a beer or two I'm convinced emacs and org mode approaches are worth emulating in the web.
Great article and linked discussions. Thanks for sharing.
It's like creating regulations which require a specific solution before that solution exists.
> its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes
That's what I miss about it.
In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course).
There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ be slightly more performant from using a lower level of templating, as an optimization, but I'd certainly prefer that to be abstracted away and buried deep inside React, rather than ever having to think about it myself, at the JSX layer.
Someone can let me know if React is already leveraging this for browsers that support it, I didn't research that.
The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.
Hoping I missed something because otherwise my take is that this idea is sort of misguided at least in part.
In fact I don’t see any reason a browser level “here’s new DOM you diff and apply it” wouldn’t be a huge win for React, and React is more popular than basically every other framework combined. So to dismiss solving the biggest use case reeks of “I want my solution to be better so I’ll just conveniently drop the bigger problem for something that makes my solution better”.
I don’t see any reason why a generic diff solution or some low level improvements to updating trees of DOM in batches wouldn’t be doable. Would be a huge win and could even eventually build up into a template type thing on top of it.
To build the template thing first is the classic mistake of the web API authors over the last decade - jumping to high make some huge high level concept a standard before they let the exosystem even shake out, missing the abstraction, and everyone paying dearly for it (see web components).
1. Making it possible to do something like <template src="..."> and being able to load them from an external source
2. Making them "dynamic"
3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.