The web components spec says there are four parts
- templates
- custom elements
- shadow dom
- html imports
disclaimer: I might be terribly wrong. This is a set of naive observations.
As a user of a non-html based templating languages called hyperscript I dont see the value in have a html based templating thing.
Other users of non-html based templating languages like anyone uses react also will not see any value in a html based templating thing.
Templates allow frameworks that use DOM as templates to encode their DOM templates in an inert template tag. This means that the raw un framework evaluated DOM will not render and you dont see a flash of the template source for say angular.
This is a great feature if you want to import a WC written in angular without having to see the flash of unrendered template due to the "design decisions" of angular.
As a user of a framework called mercury that discourages using the DOM directly and strongly recommends abstracting units of "HTML" in functions and higher order functions it doesn't seem to make sense to use the a "custom element" as the base unit of abstraction.
My templating system recommends you use javascript functions to express a re-usable component. Note that a re-usable component can render to DOM, SVG, MathML, Canvas, WebGL, etc. There is no need for it to use a custom element as the base unit internally.
Also note that a CustomElement is a global thing and has to be hooked into a global html token namespace to be used where as javascript functions can be imported and given any local name.
Custom elements are great as a way to export a framework specific component into a normal DOM interface.
This does suffer the global namespace problem but worse is better. Every framework can also add a generic "import custom element" into the framework.
A workflow for designers / people that write markup for websites is to write static markup + CSS to get structure correct and then later rewrite it in a dynamic templating system.
By allowing these designers to be able to drop custom elements into their static markup prototypes they can build more powerful prototypes or at least do less copy paste for tab components or modals or something.
The shadow DOM might be useful for performance reasons. It also seems to be used as an encapsulation / hiding technique which seems unnecessary.
When building static HTML web pages, or prototyping HTML for a web app it's useful to not have to see all the DOM elements in a custom element.
Seeing an element in your webkit DOM element inspector as just 'component-foo' instead of a large DOM tree is a slightly nicer workflow.
Shadow DOM gives browser vendors a spec and approach they can use to implement <input type='color' />.
It also allows the web community to build new elements we want to "land" into the browser itself using the exact same technologies browser vendors use. Although it's probably a bad idea to add more custom elements baked into the browser.
Shadow DOM may have an actual solution to truly local / anonymous CSS without namespace conflicts.
As a user of a javascript framework that uses the commonJS module system and as a user of a javascript based templating system where I can use commonJS to import other templates I see no need for HTML imports.
It turns out that HTML imports do not tell you how to import JS. Instead I think of html imports as a complement to ES6 modules. They allow you to import a html document which has links to css or links to prefetch images and a link to js.
which allows for sync rendering in importees without flash of unstyled content or non existant images.
html imports are not a replacement for ES6 modules or module tags. they are just a container element where you can synchronize the execution order of prefetches, css & js modules