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

@dmitriid While the precise syntax and semantics of what builtin templates will be included are not worked out yet ((see [this issue](https://github.com/w3c/webcomponents/issues/682))). But it'll almost certainly look something like this:

```html
<div>
  <template directive="if" value="loading">
    Loading...
  </template>
  <template directive="else">
    <template directive="for-each" in="items">
      <div>{{i}}</div>
    </template>
  </template>
</div>
```

Regardless of what the builtin semantics are I don't see how it really matters, the point of the default template instantiation processor is not to provide a turing complete language capable of doing any computation you could imagine but rather provide a good subset for a good chunk of typical use cases.

There's always gonna be use-cases that template instantiation is not going to solve by itself, for those cases there exists the DOM to do whatever manipulation on whatever data-structures you might need and quite importantly `TemplatePart`s with which to have your own insertion points for data from those structures.

---

It's also not really clear to me what you're arguing, you keep referencing your original post as if virtual DOM is some holy grail of performance and usability which is a highly subjective point at best. I personally prefer the declarative HTML form as it's a lot easier in a large amount of structural elements to separate your presentation from any data you carry.

Regarding your points:

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

Yes, I'm not clear what is wrong with this? There's already perfectly canonical ways of inserting it into the `Document`/`ShadowRoot` e.g. `.appendChild`. The typical flow would look like this:

* get the template from the document or an HTML module
  * e.g. `import { loadingTemplate } from "./loadingTemplate.html"`
* instantiate it with a processor (which might be the default processor)
  * e.g. `const instance = loadingTemplate.createInstance()`
* append it to whatever DOM you want
  * e.g. `shadowRoot.appendChild(instance)`
* update it in response to data changes
  * `instance.update({ changedKey: newValue })`

you can very easily wrap this flow into a `PureComponent` helper or something in a lot of cases. For other cases you can always use DOM as if you don't know ahead of time what structure you might be constructing you probably need some imperative logic anyway.

> Because not everything is a static HTML file. For a person who "deals with JSX daily" this should be obvious.
> Because not everything is a static HTML file. Because not everything is HTML generated on the server and sent to the browser.

Heaps of stuff is just static content that you want to include in the page for its structure rather than anything dynamic. The whole point of template instantiation is to _also_ provide you insertion points where you want dynamic data to go. And as I've already said, even when things are dynamic you almost always have a certain number of insertion points.

---

One final thing, the [spec text](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md) in this repository is not necessarily up to date or what will be implemented in browsers. There's currently a [WIP implementation](https://bugs.chromium.org/p/chromium/issues/detail?id=930048) in Chrome to implement template instantiation which simply by looking at the WebIDL definitions I can see has a fair few differences from the spec in this repository.

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