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

>  let's not get rude
hmm, when addressed towards people it is not just insulting but also counterproductive. But towards API implementation it is important to look into depth and get over 5 whys on why there is a frustration answer would reside on either decision process or particular API developers vision or lack of. 

Many stones been thrown forwards NodeList and enumerable in JS, Mutation observer, etc. Will be more towards templates. 
reading over main goal statement, it look a right direction. 

> 1. Provide a high performance primitive for template engines & frameworks to build on top of.
> 2. Provide a minimal high-level template support so that authors don't necessarily rely on a library or a framework to make a good use of templates
> 3. Provide a common framework by which different template engines & frameworks can work together

But once API would select limitations over openness, closed rather evolutionary approach the fate would follow those samples.

# JS centric vs declarative HTML approach
While JS seems to allow the max flexibility, it is a source of mistrust and no-js declarative web app is winning more popularity. 
By providing declarative-first implementation you will gain
* of course **trust** from all kind of consumers. Penetrate declaratively programmed web app would be almost impossible.
* **performance** the browser engine is empowered for lots of optimizations as would not need to account  the JS driven app logic. From parallel rendering to on-demand hydration.
* reliable base for API which would match the declarative stack. When there is a need for JS trickery, it would less interfere with browser engine based on declarative HTML treatment.

# the template source and need to inject template into DOM
Not sure why this discussion is missing the whole ecosystem of HTML modules, externally defined templates and (external-)document with multiple templates as representation of library concept.  

Good solution would account those most used aspect. 
My take the **templates shall be part of module loader** and be a application-wide (domain or descriptor-defined) cashed as document parts. As such template DOM/root used in current document. But for externally defined template source document the templates have to be reused without the need to be injected directly into current document. Page changes, templates  remain in memory and ready to be reused or offloaded. Which of course is not (yet?) a part of current DOM model.  

Back to subject of current discussion, how the template is exposed to JS would be up to developers, but platform should support all essential needs:
* available from same document DOM when provided
* load from external document (DOM), loaded on demand
* from html module ( ideally would match case ^^ but seems proposal goes "wrong" direction towards string presentation)
* re-defined in runtime(dynamic templating) by `innerHTML`/custom DOM fragment.

may be few more methods.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/704#issuecomment-1229360327
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/704/1229360327@github.com>