Re: [w3c/webcomponents] [templates] Ensure that template instantiation actually improves the platform (#704)

I realised I've been absent from this discussion for quite some time. But, you know, there's always someone wrong on the internet, so my attention got diverted :)

I realised the main reason we don't agree on what template instantiation. Template instantiation presumes that the template already exists. That is, it's a static chunk of HTML (as a string?) with some dynamic parts described using the moustache syntax. And then that static chunk gets applied to the document.

See for yourself (I'll use the quote format to present all my arguments as a single chunk):

> 
> > with the HTML Modules proposal which is hopefully going to ship soon, it won't be necessary to use .innerHTML to create a template object ready for fast cloning. 
>
> HTML Modules assumes there's already some static HTML defined and ready for import
>
> > what templates bring to the table -- the ability to quickly clone a chunk of HTML, and add it to the tree using appendChild.
> 
> This assumes that the HTML chunk already exists
>
> > That's more or less NodeTemplatePart and AttributeTemplatePart aim to provide. When you set a new value to a template part, the browser can figure out whether the change actually needs to propagate to the node
>
> This also assumes that those parts are already there, and inserted into the document
>

However, the only reasonable API for creating those templates? Probably `.innerHTML` :)

So, in my mind, the template instantiation proposal for some reason separates creating and updating dynamic HTML into several stages:

- somehow create the template (how?)
- somehow insert it into the document or into another template (how?)
- when values change, call `.update`, and the values will be updated (the proposal)

However, from the point of view of most developers (yup, speaking for everyone here :) ) there's only one stage: given a certain state, update the DOM.

A common example: Load a list of items. While they are being loaded, display "Loading". Once they are loaded, display them.

In most templating systems, or in any JS-only approach like React's JSX, it's the same thing:

```js
// using JSX
return <div>
   {{ loading ? 'Loading...' : items.map(i => `<div>${i.name}</div>`}) }}
</div>
```

Template Instantiation as it currently stands has no support for this use case:

- conditionals "can be implemented by libraries and frameworks" (so, not a part of the proposal)
- loops have at least three different solutions, all with their drawbacks
- in all cases the developer would have to create a separate template just for the list of items to be able to display them instead of "Loading...". Which comes back to "how?" :) And how will the get into the original template in the first place (`.update` or `.appendChild`?)

And that's just for the most simple use case.

---

I also doubt these new APIs will gain any significant adoption as "a common set of primitives for various libs and frameworks to work together". To begin with, there already is a common set of primitives, the DOM API ;) But the main reason is that I doubt template APIs provide any significant improvement over what current generation of libraries and frameworks have to deal with:

Now | With Template APIs |
--- | ---
Only some can be "rehydrated" from static HTML | More or less assumes the template is already present as static HTML
Can create any complex structure on the fly | Unless already defined as static templates, you will have to do what libraries and frameworks already do
Manually create DOM nodes and append/insert them into the document for dynamic parts such as lists/list items | Manually create DOM nodes and append/insert them into the template (unless it's already a template, then manually instantiate and append/insert)
Manually keep track of changes to change the DOM only as needed | Same (the proposal doesn't specify how the browser should work with data changes)
Manually track changes in lists of items (commonly using `key` attribute) to make sure lists are not re-rendered in their entirety | Possibly same, possibly not. No idea how the browser will re-render items in a loop
Use any and all tools at your disposal: create any template/DSL you want, or use JS. | Restricted to a very limited subset of moustache syntax with callbacks into JS. Conditionals left to libraries and frameworks, loops are not specified yet.

In my opinion, this is a marginal improvement at best, and the cost is significant. I've already talked abut it here: https://github.com/w3c/webcomponents/issues/704#issuecomment-478696830

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