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

Hi @dmitriid,

Thanks for helping get the conversation back on track (though I did think the previous two comments were quite on-track and informative as well).

>In 2019 why is there no better API than dumping blobs of strings into DOM via .innerHtml?

Excellent question!  I wish with all my heart that HTML Modules / Imports would have received, in conjunction / parallel with ES Module imports, the same degree of attention the past few years that ES Modules did.  But I guess, bowing to the fact that JS imports was in higher demand (an example, in my mind, of questionable coding practices begetting questionable priorities from the standards committees), HTML Modules (and people like me who prefer to send data in their native data format) took a back seat.

But I have good news for you -- with the [HTML Modules proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HTMLModules/explainer.md) which is hopefully going to ship soon, it won't be necessary to use .innerHTML to create a template object ready for fast cloning.  The server can send a <template> tag with the HTML that needs rapid cloning directly in the document!  No API needed at all!  But I disagree with you that that answer makes template instantiation less useful -- quite the opposite.

What I'm not yet picking up from you is a recognition of what templates bring to the table -- the ability to quickly clone a chunk of HTML, and add it to the tree using appendChild.  I.e the ability to work with repeating data, like grids or virtual lists (or multiple instances of the same web components) efficiently.

I do share the general hope with you that, should template instantiation / and rapid updates of the cloned DOM tree ship in the browser, that whatever low-level functions are needed to do that in as fast a manner as possible -- a DOM Diff engine of sorts, in other words -- that where possible, (some of) those low-level functions might also be added to the platform, which could benefit other scenarios, such as scenarios where the original HTML didn't come from a template, but may have instead come from server-side rendered HTML.   I.e., tell the engine via an api where to locate the "parts" for rapid updates. Scenarios where the HTML isn't very repetitive, which doesn't exhibit the kind of repetitive structures templates are designed to optimize.  Or scenarios where a client-side API is used to generate the entire HTML structure without the help of templates (hard as it is for me to imagine why that would be the right approach).  


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