←back to thread

The time is right for a DOM templating API

(justinfagnani.com)
218 points mdhb | 1 comments | 26 Jun 25 19:23 UTC | HN request time: 0s | source
Show context
quantadev ◴[26 Jun 25 21:57 UTC] No.44391894[source]▶
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.

replies(2): >>44392016 #>>44392258 #
rictic ◴[26 Jun 25 22:56 UTC] No.44392258[source]▶
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.
replies(1): >>44392548 #
nwienert ◴[26 Jun 25 23:43 UTC] No.44392548[source]▶
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.

I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.

Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).

replies(1): >>44392658 #
1. quantadev ◴[27 Jun 25 00:05 UTC] No.44392658{3}[source]▶
I still have hope for Web Components to take off in the figure. I'm a React dev so I don't "need" them, but they may end up being some kind of capability that React can secretly, quietly embed into React core as some kind of optimization if that ever makes sense. Web Components is a great idea, but like I said it's just not quite as convenient as React, so it's currently somewhat irrelevant at least for me.