[HN Gopher] The time is right for a DOM templating API
___________________________________________________________________
The time is right for a DOM templating API
Author : mdhb
Score : 50 points
Date : 2025-06-26 19:23 UTC (3 hours ago)
(HTM) web link (justinfagnani.com)
(TXT) w3m dump (justinfagnani.com)
| PaulHoule wrote:
| 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.
| WorldMaker wrote:
| 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.
| wg0 wrote:
| Need a DOM snapshot API too.
| insin wrote:
| We'd need a good API for UI components to go with it
| quantadev wrote:
| 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.
| Gualdrapo wrote:
| "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.
| rictic wrote:
| 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.
| segphault wrote:
| 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 wrote:
| You don't even need much: loops, conditionals on attributes,
| and conditionals on nodes.
|
| In fact, we could have that cross-language.
| mosdl wrote:
| I miss mozilla's XUL language (and XBL!), those were awesome.
| latortuga wrote:
| 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!
| watersb wrote:
| there-is-only-XUL
| rs186 wrote:
| The author was a core contributor of Google's Lit project:
| https://github.com/lit/lit
| bevr1337 wrote:
| 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.
| lofaszvanitt wrote:
| Fisrt include jQuery as a whole into the base standard. That
| would help a lot.
| edoceo wrote:
| I <3 jQuery but, no.
| lofaszvanitt wrote:
| What no? Why can't we have nice things, like concise, easy to
| remember, not overly elaborate syntax?
| bravesoul2 wrote:
| Out of FE for a whole but isn't that done to a great extent.
| pier25 wrote:
| 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.
| bravesoul2 wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-26 23:00 UTC)