The time is right for a DOM templating API
justinfagnani.com
The time is right for a DOM templating API
1–10 of 256 posts
Re: The time is right for a DOM templating API
#2https://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.
Re: The time is right for a DOM templating API
#3What 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 stri…
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 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) and 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.
Re: The time is right for a DOM templating API
#4Re: The time is right for a DOM templating API
#5Re: The time is right for a DOM templating API
#6In 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.
Re: The time is right for a DOM templating API
#7The 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.
Re: The time is right for a DOM templating API
#8Templates 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_ b…
1. Making it possible to do something like 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.