[w3c/webcomponents] Use cases for HTML Imports (#573)

I would like to put some feedback on use cases that we cover with HTML Imports and benefits we see in current version of spec.

So far we have found HTML Import a very useful concept.

We are providing an application platform, what involves heavy usage of composing the UI from multiple sources, multiple vendors and on multiple levels.

## Use cases:
1. Loading regular Custom Element's definitions
That's the use case heavily advised, and described by Polymer. We use HTML Import to load a chunk of HTML that contains script that defines custom element, markup for (many) templates that will be used by CE, style to be applied, and links for related dependencies

2. Packaging many dependencies
As a app platform, we only require application vendors to use single line in HTML (currently with `link rel="import"`) to attach bulked package with all dependencies needed to use our server- and client-side features. So, we can easily change them (update versions, replace one package with another, inject debugging tools etc). We do so without any opinionated build tool, so application vendors are still able to pick out to minify/concatenate/build their code with our dependencies.

3. Partial/Includes/SPAs
Most of our clients are interesting in building SPAs. We can finally help them do so in framework-less manner, with single Custom Element.
(I described it in details at http://starcounter.io/html-partialsincludes-webcomponents-way/)
We are able to use it to dynamically load fully-featured HTML parts of view:

 1. App author uses custom element (e.g. ['imported-template'](https://github.com/Juicy/imported-template)) to indicate the place where to include the dynamic content.
 2. Content could be easily changed HTML-way. Once attribute is set/changed, the CE adds `<link rel="import">` to load the content from external file/server-side endpoint
 3. Once import loads it's processes in very structured and desired way (driven by browser): it imports related dependencies, executes attached scripts (which may load js dependencies, do some preparation, etc.) 
 4. After document is loaded the CE stamps `<template>` from external, imported document (which may also use styles, scripts (run per each instance, to support non-CE widgets, etc.)
 5. Same template could be stamped many times (iterating for lists, tables, multiple usages)

 Such use case
 - does provide standardized way to do partials for all the apps,
 - ... what helps us to mix them together, without any need of cross-integration between them,
 - could be easily nested and composed as it becomes part of HTML,
 - plays well with any WebComponents-ready data-binding,
 - get's additional boost from HTTP/2,
 - is way much more convenient that use of iframes (markup and scripts are isolated from main document)


So far all above use-cases are used by [Starcounter](http://starcounter.com/) application platform and at least 4 independent companies I'm aware of, and we are happily using it on production for ca. a year.

----

The only problem that we see with HTML Imports is that `<scripts>` included in separated imports are executed many times, but so far we have found few workarounds for that, and we hope it could be solved with ES6 modules.

-- 
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/573