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

@bahrus I engage in this conversation in good faith. You engage in thinly veiled trolling.

For the sake of others in this thread, I'll respond to some of the things you mention:

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

Because not everything is a static HTML file. For a person who "deals with JSX daily" this should be obvious.

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

Because not everything is a static HTML file. Because not everything is HTML generated on the server and sent to the browser.

> I get that I'm the freak here who likes the syntax of Vue and Svelte more than JSX.
> 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?

1. React is not my beloved. 
2. Vue's template syntax is completely different from chosen in this proposal
3. Svelte's template syntax is completely different from chosen in this proposal
4. The proposal specifically states which syntax has been chosen

One more reason to think that from the offset you weren't interested in an honest discussion.

> I suspect it's that very concern that causes the proposal to be so vague and leave so much up to the frameworks

The proposal is very concrete in all the places that sort of really matter (how to get data into the templates), and is vague in all the places where it matters (conditionals and loops).

So, no, I'm not thrilled by things being left to library and framework authors _yet again_ when we could have high performing APIs built into the browsers, and not reimplemented time and again in incompatible ways in hundreds of different frameworks.

> 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

Your bullet points are invalid in the context of the proposal. Moreover, I gave a concrete, simple example, which would be rather painful to implement within the confines of the proposal, especially when HTML is generated dynamically.

I also showed all the ways the proposal is not strictly or much better than existing approaches for all the reasons that the proposal omits, and for all the reasons that this entire discussion deliberately omits.

If you think this proposal obviates the need for existing frameworks, or that React/Vue/Preact/morphdom/hyperHTML/<dozens of others> will give up on their declarative APIs on top of their internal Virtual DOM implementations, your wishful thinking is much greater than mine. This proposal can't even tell how to deal with lists of DOM elements, or how a browser should behave when the actual `.update` call happens.

> So I don't know what to think.

Indeed.



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