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

@LucaColonnello 

>Writing an if statement in a string attribute was never an appealing approach, and still isn’t.

Never appealing to whom?  If just you, with all due respect, I don't think that should drive this decision :-)

[Vue](https://www.geeksforgeeks.org/vue-js-conditional-rendering/#:~:text=Conditional%20Rendering%20in%20Vue%20makes%20it%20easy%20to,can%20be%20used%20to%20conditionally%20render%20a%20block.), AngularJS, and other templating syntaxes use admirably concise if/else logic based exclusively on attributes, that appeals to many members of the development community, for its sheer conciseness and readability, I think.  We should be so lucky if template instantiation could support that.  Unfortunately, due to Template Instantiation wanting to best represent how the conditional is understood internally, without a build step, it may not be practical / worth the effort to represent conditionals so concisely, and may have to mirror the verbosity of svelte, React, and tagged template literals.    [This is what that looks like in practice](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/create_conditional)  I think we can live with that.

A number of JSX-based frameworks, including [Solid JS](https://www.solidjs.com/tutorial/flow_show) also don't consider use of attributes to be so scandalous when representing conditional statements.  I just don't see what is so unacceptable about use of attributes, especially if it can make the syntax less verbose.  What am I missing?

It should be remembered that although querySelectorAll barely made a dent in JQuery's market share, JQuery was able to reduce its size and complexity by utilizing it (it had to keep the sizzle engine in place because it supports queries not yet supported by querySelectorAll), while preserving its API.  I think querySelectorAll was worth it for that reason alone.  I don't know what percent of the existing frameworks would lean on Template Instantiation in a similar way.  Certainly not 100%, but I suspect a good number would.  And it could also lower the barrier to entry of new ideas, especially if template instantiation's performance is in the same ballpark as existing ones.  I agree it might be a hard sell for libraries that clock in under 3KB, if the performance is the same.  But even for those libraries, hydrating with declarative shadow DOM, from a shared template, [is a prominent use case](https://web.dev/declarative-shadow-dom/#shadow-per-root) that I suspect even those libraries would make use of.

What I *think* really underlies the concern that is being raised here is whether unfettered access to the JavaScript runtime should be permitted in the template syntax (however, apologies if I am misreading the concern). 

If there *is* a goal to reduce the need for UI libraries on top of Template Instantiation, then that is certainly a factor to consider, and I agree that without it, the number of use cases of relying exclusively on Template Instantiation is reduced.  But I don't think it should be the primary goal (and has been clearly stated as not being the goal). 
 
Maybe there can be multiple levels of access permitted, passed in as an optional parameter to the template instantiation engine, based on the trust level that is in place between the code that executes the template instantiation, and the providers of the templates (similar to how iframes use the sandbox attribute).  The parameter could have at least three levels:

1.  Only built-in, minimal if/else / looping logic with only safe, low hanging fruit for common things like null condition alternatives (??) number / date formatting, etc.  This syntax could be used by CMS's like [WIX](https://support.wix.com/en/article/wix-editor-adding-a-custom-element-to-your-site) or Micro Front Ends.
2.  Allow unfettered access but only within a provided [Shadow Realm](https://fjolt.com/article/javascript-shadowrealms).
3.   Allow 100% unfettered access.

Microsoft did something like that with XSLT, actually (allowing JavaScript execution), as shown [here](https://docs.microsoft.com/en-us/dotnet/standard/data/xml/script-blocks-using-msxsl-script).   That ability was removed from .net core, unfortunately, if anyone cares.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/704#issuecomment-1196107517

You are receiving this because you are subscribed to this thread.

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