Re: [w3c/webcomponents] HTML Modules (#645)

Thanks all for answering [my question](https://github.com/w3c/webcomponents/issues/645#issuecomment-312001680).

I am reading the feedback that generally loading HTML as a dumb resource, though available not as raw HTML text but as parsed DOM tree, would be enough for many use cases. It's understandable, though I'd like to argue that it will not cover some aspects of HTML Imports.

I agree that *generic imports* is an idea that is worth pursuing. So my current thinking is, that whether we should divide the current discussion into *generic imports* part and other parts.  At least, for separating concerns, it would be beneficial for both discussions clearer.

Re https://github.com/w3c/webcomponents/issues/645#issuecomment-312136678
for @AshleyScirra, as @bicknellr already mentioned, generic imports would still go through DOM / HTML / TC39 standardization process.
As @annevk already mentioned (https://github.com/w3c/webcomponents/issues/645#issuecomment-311637245), ES6 module imports require MIME type to be specifically JavaScript (e.g. `application/javascript` etc.) today, otherwise rejected. But by allowing some other MIME types (e.g. `text/html` or `image/png`), without `as Z`, loaded content could be inferred from their MIME types.

For HTML, if it is just for fetching and parsing, the capability is limited, which could be good, but that's not very different from what you can do today with `fetch` (though dynamic, and unfortunately [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) doesn't have `.document()` while [xhr.response](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/response) has).

Moving back to the old comment (https://github.com/w3c/webcomponents/issues/645#issuecomment-310840488)
> This moves almost the entire HTML imports functionality in to a library, rooted on the JavaScript module system.

This may be true, in terms of functionality.  But what about performance (including loading performance)?

To review what HTML Imports are good at, here's a list:
- Transitive dependency loader with de-duping (ES6 modules have, but resolves statically, not transitive)
- Leverages existing native parser(s) for JS/CSS/HTML (generic imports could have)
- Non-blocking (async loading & parsing, ordered evaluation) (ES6 modules are sync, single-threaded)
- Allows declarative development (HTML-first vs. script-first)
- Easy transition from existing HTML resources

Another thing is that HTML Imports could use [preload scanner](https://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/), which may improve loading performance of subresources. Though the quoted blog is somewhat old, and in the age of HTTP/2 and [`<link rel=preload>`](https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/) we want to reevaluate its usefulness.

-- 
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/645#issuecomment-314716073