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

Thanks, @dmitriid, for your civil and non-rambling response :-)

I agree templates are a key part of the web component stack, and in retrospect you were replying to a message arguing why an (apparently) small library like what template instantiation would (apparently) entail should be built in to the platform, and the argument was made that it would benefit declarative custom elements.  

But more generally, I for one have taken the liberty of using templates without web components on a number of occasions, and I don't think I'm alone.

I actually agree with you that the platform would benefit from some helper functions for those scenarios where a programmatic api is needed -- one that improves upon Object.assign, one that is specifically tailored for setting properties / attributes / events on a DOM element, i.e. a similar purpose to what you are laying out. 

For example,  I've been toying with a function I call ["decorate"](https://github.com/bahrus/trans-render#declative-ish-property-setting--behavior-enhancement), which I modeled after Vue/Polymer 1, but now realize, thanks to your bringing it to my attention, is quite similar to h.  

The difference is that this decorate function is applied to an *existing* element, coming from a template  or existing DOM tree, rather than being only useful for generating the HTML data structure itself.

I do think, given the wide range of libraries doing something similar, having something built in to the platform would be useful.  Just my two cents.  But so would template instantiation.  I don't see why one precludes the other.

If a template api/syntax has built in functions to do certain things (like for-each), i.e. officially sanctioned functions, that is quite different from saying you can use any user-defined function you want.  For a concrete example of what I'm getting at, I need to change the subject slightly:  Take the github developers who are managing the github web site-.  They are defining web components, which can enhance the markdown vocabulary.  I recently realized I can use their custom elements in my markdown!  Github only trusts that because they trust their own web components.  They won't allow us to use arbitrary web components, for fairly obvious reasons.

I'm not saying user-defined functions must be forbidden in template languages, only that it is a significant line one is crossing, one which could be use to separate "non-declarative" vs "declarative" in a coherent (I think) way.

I suspect the author of hyperHTML would take issue with the statement that it required  dozens or hundreds of engineers to match the performance of h based libraries :-).

Thanks for the link to your critique of tagged template literals. I'll take a look.


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

Received on Thursday, 21 March 2019 17:08:30 UTC