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

Thanks @dmitriid  for taking the time to patiently explain why I am wrong :-)

To be honest, I've come to realize that there seems to be an "East is East and West is West and never the twain shall meet."  I think we are at opposite poles in terms of what appeals to us, and the point of discussing further seems to be pointless, though it makes for good comedy.  Maybe we should start an act? :-)

For example:

> Template instantiation presumes that the template already exists. 

This is our fundamental disagreement?  Is this a "chicken or the egg" type puzzle?

[It exists.](https://www.w3schools.com/tags/tag_template.asp).  [And is widely used.](https://www.chromestatus.com/metrics/feature/timeline/popularity/2769).

Why not make it even more useful?

> somehow create the template (how?) ... 
> However, the only reasonable API for creating those templates? Probably .innerHTML :)

In the context of an HTML Module, the mystery eludes me.  Why use an api?  Why not type the text of the template into a static file?   That doesn't use innerHTML.   Or copy and paste from the first link above into a static file?  I don't see an innerHTML button on my mouse.  If the template to be cloned contains some pieces of semi-live data (but which will be repeated in every instance on the client) why not use  PHP?  Asp.net?  [The sky is the limit](https://www.similartech.com/categories/framework).  Few if any of them use innerHTML to my knowledge.  Surely, you know this, so I start to think you are speaking in some deeper level way beyond my comprehension.  Are you using "innerHTML" as an allegory for something deeper? :-)  

I'm afraid I don't have a good ear for poetry :-)

I get that I'm the freak here who likes the syntax of Vue and Svelte more than JSX.  (Actually, I'm pleasantly surprised you appear to be warming up to template literals in your JSX example?)  I work with JSX on a daily basis, and isn't my cup of tea.  Sorry.  That's just me. There's no accounting for taste.

And we still have plenty of performance problems, which has certainly not increased my affinity for it.

And by the way, I do share the concerns raised by Jan and Mildred above that the ability to apply transforms beyond what inline binding can provide is quite important.

If I may be so bold, could I suggest that what is really bothering you is that the proposal appears to favor the syntax of Vue and Svelte over your beloved React?  I think that is a valid concern, but that may just be a kind of "illusion".  In fact, I suspect it's that very concern that causes the proposal to be so vague and leave so much up to the frameworks, which you are using against it.  I see that as a feature, not a bug.

I look for common goals when I communicate with others-- surely performance is a common goal?  But you don't seem to want to engage in the question I find most interesting --  whether it's faster to generate a list by:

1.   Cloning a template with placeholders for data.
2.  Filling in the data into placeholders (which could already be quite fast, but template instantiation would make faster), and
3.  Appending to the container using appendChild, 

vs.

...
Whatever it is that your compiler does with the JSX / template literal you provided?

And that's the thing.  The compiler would presumably do whatever is fastest.  That could, today, already be using templates without the instantiation proposal.  Or maybe not.  Maybe it's lots of appendChilds, which I think React uses.  Maybe its lots of innerHTML's, which I think React used to use, but concluded lots of appendChilds is faster (I remember reading that a long time ago, but can't find it now).  Interestingly, the folks at ag-grid concluded the opposite ([see Hack 5](https://www.ag-grid.com/ag-grid-performance-hacks/)).  So I don't know what to think.

I'll give you the last word as we are going in circles

 



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