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

I would like to remind you all of the original question raised:

> Before adding anything as complicated as https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md it is better to ensure it improves the platform.

Once again, this proposal introduces an objectively complex:

- a new templating language (incompatible in syntax and behaviour with everything else in the ecosystem)
- that is both very limited in functionality (poorly specified/underspecified if and foreach as the only control structures) and unlimited in functionality (we can call functions in the host language)
- that is alien to the system (literally nothing in the platform looks or behaves like this)
that requires a different parser, a different execution model, hooks into the rest of the platform to make it workable
- solves the main use case of composing components poorly, or not at all (you need to nest template elements within template elements within template elements...)
- doesn't specify how you would instantiate elements not from static sources, but from dynamic data (I'm guessing .innerHtml again?)

And introduces only marginal improvements (if they are improvements at all). And on top of all that it basically leaves nearly everything to the libraries and frameworks.

---

Yesterday I came up with the simple "Loading..."/list-of-DOM-elements example. The solution suggested by @Jamesernator already shows how horribly cumbersome the alternative provided by proposal is.

Then I realised there's an another example:

```
<button onclick="{{ f }}"></button>
```

The proposal provides no way of dealing with this except manually parsing this, figuring out what the attribute is, setting up the listeners etc. That is, once again, delegating everything to the libraries and frameworks. And these are not corner cases, or edge cases. These are actual use cases that people come up against every single day.

So, instead of giving the power to end devs, once again, the standards opt for "we're going to introduce a very limited, underspecified, cumbersome API that is only aimed at developers of libraries and frameworks". Can we stop this trend, please? :)

---

@Jamesernator 

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

Would you please give me at least a sliver of respect and read what I am actually writing. For example, here: https://github.com/w3c/webcomponents/issues/704#issuecomment-478696830 where I actually talk about _killing the need for VDOM_

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