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.

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 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.

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.

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.

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?

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?

It's like creating regulations which require a specific solution before that solution exists.

More specifically, a native implementation of the "patch" function:

    patch(target_dom_node, virtual_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.

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?

There has been long running complaints about how many UI frameworks there are, and how often they change. It's settled down some, but I don't expect that situation to change for a long while.