Decoupling rendering logic from core x-element logic and rolling our own internal templating engine would provide the following benefits:
Zero Dependencies — This makes installation, integration, and consumption of this library incredibly straightforward and tightly controlled.
Simple by Default — A major goal of this project is to keep the interface size to a minimum. It's not meant to do it all. By rolling a custom templating engine, we can (1) expose only functionality that we think is necessary and (2) allow integrators to pick their own templating engine if ours doesn't meet their needs (e.g., lit-html or µhtml).
How might the interface change?
This list is incomplete and subject to change — but, to give an idea:
Fewer built-in template utilities. Over many years of developing Web Components, we've grown to favor a pattern where attribute/property/content values are managed by the element such that the render loop is incredibly simple and lightweight.
Less syntactic sugar. There are really only three things a templating engine needs to consider — attributes, properties, and content. As long as there is a way to inject these core things, everything else can be managed outside the templating engine. This may prevent blurring the lines between separate areas of concern. For example, the ? and @ behavior may not strictly be necessary.
Stricter interpolation patterns. By more clearly defining what is/isn't valid interpolation, we can nudge integrators into cleaner code. For example attr="foo-${value}-bar" is quite complicated to read and difficult to internally manage — instead, we could insist it be written as attr="${value}", where value is computed elsewhere to be foo-${userInput}-bar or some such. Additionally, we could consider not supporting interpolation within <style> tags at all.
Decoupling rendering logic from core
x-elementlogic and rolling our own internal templating engine would provide the following benefits:How might the interface change?
This list is incomplete and subject to change — but, to give an idea:
?and@behavior may not strictly be necessary.attr="foo-${value}-bar"is quite complicated to read and difficult to internally manage — instead, we could insist it be written asattr="${value}", where value is computed elsewhere to befoo-${userInput}-baror some such. Additionally, we could consider not supporting interpolation within<style>tags at all.