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?

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?

I like the spirit here, but I would argue we need a few lower level APIs built into browsers first instead.

It will be near impossible to get everyone to agree on a standard template system. What the browser CAN do, however, is provide some lower level APIs on how to apply diffs to the DOM in a performant native way.

I would LOVE for something like this to exist in browsers natively:

element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })

This could apply the diff in a way that would be non-disruptive, i.e. it would keep element focus, input values, states in audio and video players, mutate attributes, etc. There are JavaScript libraries that do this like Idiomorph, but a native solution has the potential to be much more performant.

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.

> If the Records and Tuples proposal were progressing, JSX could maybe create Records with boxes, but that proposal has been stalled, especially on the record identity and box parts that would make it suitable for a JSX semantics.

That proposal hasn’t just stalled, it’s been withdrawn. https://github.com/tc39/proposal-record-tuple/issues/394

It has been replaced by https://github.com/tc39/proposal-composites

Is there anyone else who feels kinda like declarative templating is actually kind of worse than jQuery? Don't get me wrong, I've been using React for nearly a decade. But the more complex my SPAs become, the more I wish I had imperative control of the DOM.

I think the reason is because the DOM is a leaky abstraction and at some level I would just prefer last write wins.

I realize declarative templating is supposed to handle that, but this starts to break down really quickly when you share mutable state between components.

It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.

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.

This is exactly the kind of high-level feature we need to stop putting standardisation efforts towards, and focus instead on low-level features that provide value for high-level user land abstractions.

There is no value this provides over making a tagged template function and exposing it as a library. If that library is stable with ubiquitous adoption for 5-10 years then maybe there's something to talk about.

I don't quite understand. The DOM is/needs a functional API. Why bolt another DSL on top?

Now you have to find a way for javascript to interact with your template language.

While functions are sufficient. That doesn't look like orthogonal language design.

> There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default.

setHTML() is already implemented in Chrome/Edge and Firefox so this point is a bit outdated - there is a safe alternative to innerHTML.

> There are in-flight proposals for very low-level DOM update primitives, like DOM Parts, which target framework implementations, but I think higher-level APIs like full declarative templating can take even more load off, help prove out and complete the lower-level API proposals, and be really impactful for developers and users.

There is an alternative suggestion to DOM parts which might be a better bet: https://github.com/whatwg/dom/issues/736

The author was a core contributor of Google's Lit project: https://github.com/lit/lit

There is still innovation happening in frameworks. I do wonder if it is too early to start adding things like this to the browser. Web components landed way too early and now we’re stuck with them.

The answer is here on the HN Start-page: XSLT

I would argue that the proliferation of frontend frameworks is evidence is that we -don't- know what the optimal abstraction is for building frontend applications. We're all still trying to figure that out.

Just look at what happened with Web Components. It didn't take over or become the foundation of everyone's software. It just became yet another competitor [0].

I wish the standards committees would focus their efforts on improving JavaScript the language. That has a much greater and more lasting return on investment.

[0]: https://xkcd.com/927/

no point pushing declarative sugar again into a system that's already kinda moved on. native templating not fixing real pain = state sync, fine grained reactivity, perf edge cases. we might need a browser level primitives that let lib authors build better abstractions without the payload tax. we maynot need another xsl reboot

DOM templating is just like JavaScript classes. Classes in JavaScript were requested since the earliest of times and always rejected until ES6 (2014), because they are/were:

* always unnecessary

* always artificial

* only vanity

* only desired by insecure persons not familiar in the technology

* only qualified as bad idea but necessary because people were just going to do it anyways

So far the DOM has managed to escape this stupidity only because it is not a part of JavaScript. Java people ignorant of JavaScript desirous of features to make JavaScript feel more like Java has no bearing on the DOM, for example, because they are separate technologies managed by unrelated organizations.

None of the ergonomic reasoning mentioned in the article are qualified. Just because many people lack confidence in the technology and knowingly make poor design decisions doesn’t mean a familiar vanity layer will fix anything. Declarative comfort, for example, is not a resolution to performance and security problems just because other knowingly bad design decisions are worse. Two wrongs don’t make a right.

Furthermore the DOM already has a slow unnecessary declarative abstraction layer insecure people cannot live without called querySelectors. In other words this proposal is to React as querySelectors are to jquery, and classes are to Java. These are/were trends and trends die over time. We really should move past vanity as an alternative to an absence of training.

What exactly is the problem with having the higher levels of web development supported through libraries (React, Vue etc) rather than directly in the browser? Why does this need to happen?

I miss mozilla's XUL language (and XBL!), those were awesome.

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

Nit: The post keeps referring to "standard JSX" as though trying to will such a thing into existence.

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.

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.

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)

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.

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.

The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible.

I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one.

But these abstractions have a huge mental / implementation cost.

The problem, as with most engineering things is a tradeoff problem. The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.

Most apps out there don’t need to be crazy fast, and people will choose react because it’s just simpler.

But signals don’t really have anything to do with templating, do they? So why do we have to choose, could we have templating and signals as separate things?

Well OP thought about templating and realized you do need a way to tell the dom how to fit your templated node where it belongs and update it when things change.

And this is where these proposals fail. There needs to be a choice here. The API must pick a side (well technically it could allow for both, but ugh), and developers won’t ever agree which side it should go.

The big problem of UIs has always been how they update, not how they’re defined. Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not, all of them were painful AF. Then imgui come and say, well what if UIs didn’t have state at all. Ooh this is nice, but kind of hard on the cpu, so what do we do?

Well, perhaps one of the biggest reason for the success of web apps is in fact that the dom didn’t impose a way to bind data to its view. And so we may be doomed to framework hell.

> This kind of templating is the cornerstone of all modern web frameworks and rendering libraries these days, all of which let you declaratively combine markup with data

Okay but just because fighting the river has become popular doesn't mean wanting to pave over the river is a good idea. It might be the logical _conclusion_ to fighting the river, but you could also just... stop fighting the river and use it the way it was intended to be used again.

When are we done adding everything into the browser API?

If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed.

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.

We'd need a good API for UI components to go with it

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.

Need a DOM snapshot API too.

Where's the code?

I disagree on the general principle of adding APIs -- the platform suffers not from lack of APIs, when you really think about it, but from "another API to rule them all". It's frankly a similar fallacy that struck Microsoft where they were for a long time stuck having to support every API their seniors and interns ever invented -- none of which seem to be sufficient, apparently.

The solution to the "bro, just one more API, please" is to design a _transparent_ platform that is well able to "delegate" programming of new features (e.g. one implementing your favourite templating API) to third-parties in a manner that maintains their "first class citizen" status. WebAssembly was a move in that direction because it's a generic platform that in part supercedes and otherwise supplants the mess that JavaScript has to manage bridging the originally "kiddie script" application software domain, with the native functionality the browser may be encapsulating (also for performance).

Case in point: FFMpeg may be compiled to a WebAssembly module, which gives you arbitrary video/audio encoding/decoding -- pending correct design of bit-blitting so the decoded output can be efficiently transferred to the screen/speakers (which, for much of the reasons I am trying to outline, _is_ the bottleneck of the entire solution).

We need more of the same kind of thinking. Stop begging Web browser vendors / w3C / WHATWG for more features that are just lipstick on a pig -- sit down, think about what kind of feature(s) would allow the Web platform to finally escape the death spiral it's been in since its inception -- albeit one with a large enough radius it's meant to never actually resemble a spiral.

I don't know if I am making myself clear here, but in much simpler terms: why should there be another piece of code that caters to "most" (because you happen to be a FP/React zealot, for better or for worse) when these people can ostensibly write such templating system themselves, publish it on e.g. NPM and/or pull it and use it from there?

The time has been right for Yonkers -

[dead]

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.

Fisrt include jQuery as a whole into the base standard. That would help a lot.

Stop adding more complexity to the browser and making it even more impossible to build a new browser from scratch.