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

> Would you please give me at least a sliver of respect and read what I am actually writing. For example, here: #704 (comment) where I actually talk about killing the need for VDOM

I have read it and your proposed solution is essentially still just a VDOM/tree-diff except generating a patch on the server-side instead of the client. However this forces the server to handle all work which may or may not be desirable depending on your application.

It's definitely not bad but it definitely has some major drawbacks:
- Behaviour can't be shared between different server languages for public components so now you wind up re-implementing things in every other language
- You require a persistent connection to a server and can't delegate work easily to the client side
- Offers no solution for structure on components which need to be rendered on the client side due to client-side information required

And also note this approach still can suffer the usual tree-diff issues:
- Elements might lose state if they're removed and re-rendered (e.g. `<video>`), in contrast with templates you have the decision as to whether or not to re-use the same tree again (or any strategy you want)
- You need another copy of the DOM itself rather than just the data that changes. In this case it lives on the server side and costs server resources to maintain

> already shows how horribly cumbersome the alternative provided by proposal is.

"horribly cumbersome" is highly subjective, regardless you could propose your own alternative syntax if you feel strongly about it and believe that more concise syntax would significantly improve adoption.

I would personally prefer something like `<for.each in="loading"><!-- contents --></for.each>` but it's not clear what impact this would have on existing HTML parsers that expect only `<template>` to have parsed but inert content. I think I'll raise the matter on the issue about the default processor because I'm not super clear if it would actually be a problem.

> Then I realised there's an another example:

Again there's an [open issue](https://github.com/w3c/webcomponents/issues/682) which is specifically about the capabilities of the default processor. I do suggest proposing any things you think will be really common use cases there.

> The proposal provides no way of dealing with this except manually parsing this

Even in underspecified current spec there's absolutely nothing that requires you to parse it yourself. Just delegate to the default processor to handle parsing and replace any `AttributeTemplatePart` with your own parts in `

> we're going to introduce a very limited, underspecified

I highly doubt that proper spec text won't be released before the feature is shipped.

---

Regarding your original points:

> a new templating language (incompatible in syntax and behaviour with everything else in the ecosystem)

I don't know what you mean by "incompatible in syntax and behaviour", there's a wide difference in syntax and behaviour (for example Vue uses `v-bind:attr="someProp"` whereas JSX uses `attr={someExpression}`). What do you consider to be "compatible in syntax and behaviour"?

The proposal has to choose *some syntax* it can't possibly choose *all of them*, I don't see minor syntactic differences being the deal-breaker of the proposal.

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

This doesn't seem to be so much an issue with template instantiation itself as a lack of concrete spec text.

> that is alien to the system (literally nothing in the platform looks or behaves like this)

True, but that's true of any new feature.

> that requires a different parser

Nope it doesn't, I've implemented an almost full polyfill of it and the way it works in both the current spec and my polyfill is it simply looks at attribute and text nodes for `{{`. For example consider `<p attr="{{value}}">`, we don't need a new parser to handle this at all, we just check if the attr contains `{{` and if it does we replace it with a _Template Part_.

> a different execution model

I don't understand this you'll need to elaborate. But it seems to me that anything would be a "different execution model".

> hooks into the rest of the platform to make it workable

Again I don't understand this. It seems to me that anything would have "hooks into the rest of the platform", that's kinda the point of _Template Parts_ is that they hook into the DOM and can dynamically update minimal parts of the DOM.

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

This seems to be quite syntax opinionated but you haven't actually proposed a syntax alternative that you'd prefer.

> doesn't specify how you would instantiate elements not from static sources, but from dynamic data (I'm guessing .innerHtml again?)

You shouldn't need `.innerHTML` for anything. Either use DOM for the cases when you actually truly arbitrary structures, but templates should suffice for anything with any degree of structure (which is most things).

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