Re: [WICG/webcomponents] DOM parts use outside of <template> seems unlikely (Issue #1035)

Apologies for the wall of text that follows, but I want to make sure we're all on the same page regarding the current state of the proposal, based on the last meeting I attended.

@matthewp Please make sure to read that entire post through to the end. That syntax you are showing above is not what is currently proposed. A couple points about the syntax you are showing:

* Nobody ever wanted that syntax. It was originally thought that this was the *only* technical way to achieve the stated goals though. Thankfully, that has since been disproven.
* The HTML WG doesn't want to do stuff with processing instructions, so it's already been decided that's definitely not going to happen.

The current declarative syntax is inspired by 20 years of templating languages across multiple front-end and backend technologies. It's also explicitly designed to handle SSR and be backend-agnostic. No JS code needs to run on the server in order to express fully declarative templates which include both immediately rendered server values and client-side metadata used by front-ends.

Let me just review what the basic syntax is here based on my understanding from the most recent CG meeting that I attended:

Let's say you have an `<a>` tag and you want to bind its `href` to a URL for a user record, where the url contains the id of the user. You could express that like this.

```html
<a href="./users/{{user.id}}">...</a>
```

The double curly `{{}}` represents a DOM Part. What is between the `{{` and `}}` *at this time* is up for interpretation. It is treated as metadata to be interpreted however the developer wants. In the future, there is a hope that there will be an expression syntax, but it's too early to know what that should be. The goal right now is to try to define a modular, extensible syntax skeleton.

On the client, an API can be called on a DOM node to retrieve the tree's parts along with their metadata, so no DOM walking is needed, allowing templating engines to eliminate code and potentially improve their initial render times. From what I can tell, a lot of JS framework authors are *extremely* interested in the ability to mark locations in the DOM and associate metadata with those locations.

Let's look at another version of this same example, one that shows declarative SSR output:

```html
<a href="./users/{{# user.id}}12345{{/}}">
```

The `{{metadata}}` syntax can be expanded out to `{{# metadata}}value{{/}}` if you want to encode *both* metadata and an initial value, such as one that would be rendered by a server. In the example above, the browser will render the following *immediately* with no JS code involved:

```html
<a href="./users/12345">
```

*And* at the same time it will create a part and associate the `user.id` metadata with that part so that client code can interpret it if desired.

The syntax above is just the current proposal, used to prototype out the ideas. It can be changed. But most folks seem to be happy with it as it is inspired by very popular, long-lived libraries like Handlebars/Mustache and bears a strong resemblance to many modern templating engines.

Again, a key element of this is that no JS is involved in the above and the syntax is able to both encode server-rendered value *and* metadata that could be leveraged on the client.

Any server-side framework today is capable of generating output in this form. A JavaScript backend is not needed. These are key requirements of the proposal that have been stated from the beginning and considered as part of the current design. If you think there's a flaw with this, please be very concrete about the problem and make some concrete proposals for how to fix it. I think everyone very much wants to hear that feedback and is sensitive to getting this right in a way that it is broadly usable.

I also wanted to make a couple of notes about the HTML parser and browser vendor aspect of the concerns.

First, the proposal you see here is coming from browser vendors. The design has strong alignment from both WebKit and Chrome already. It originated with WebKit. Browser vendors really want to solve this problem and have a lot of motivations for doing so.

Second, WebKit has proposed a way to implement this without altering the HTML parser itself. So, that's not a real concern anymore. The parser would parse according to the normal rules. The DOM itself would make the transform after parsing, under strictly dictated conditions (the presence of a `parseparts` attribute on a parent DOM node). This is intended to work both in templates as well as directly in the document.

With respect to specific languages like Python/Ruby or frameworks/approaches like Laravel and Hotwire, I can only speak generally. I haven't used Laravel in a number of years and haven't ever written a Python web backend. It's been a while since I used Rails, but I do keep tabs on Hotwire and the other client/server paradigms the community is working on there. I do think this should all work very well in those context. We are talking about fully declarative syntax for all of this. It's just a matter of these frameworks sending down html that uses this syntax with the values they already have on the server. You can even use things like Hotwire/Turbo and HTMX with this. The server is free to dynamically send down HTML with this syntax at any time. If it has a `parseparts` attribute, it can just be shoved in the DOM like any other HTML and the browser will render the values, capture the parts, and associate the metadata automatically. This seems like it could provide some very interesting opportunities.

Ok, hopefully this helps clear up a few things. It just seemed that there was some out-of-date information. Let's continue the conversation. I'm trying to understand the concerns but am having a hard time seeing the issue with the current version of the proposal.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1035#issuecomment-1804191633
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1035/1804191633@github.com>