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

Putting *inlining module* aside, asking why `import ... from "./foo.html";` is necessary is equivalent to ask why you need `import ... form "./xyz.js";`?  You can surely inline `xyz.js` into your JavaScript code, with some namespace wrapping.

My understanding is that we use rendering engine's HTML parser + DOM construction code for importing HTML file, which can run in parallel to JavaScript parsing, and it gives opportunity for rendering engine to optimize the whole loading tasks.

I believe in your second example, `HTMLTemplateElement` function could be implemented in native code, or even JavaScript parser can pass the string to native HTML parsing + DOM construction code which may run in the different thread off the main thread, if the string doesn't contain any interpolation points.

I don't think your 3rd example doesn't work, as `import` statement has to be statically resolved before evaluating the actual JavaScript code.  Statically analyzable import statement is an absolute requirement for ES2015 modules, if I understand correctly.

So realizing `as TypeName` as an extension of `import` statement has a challenge that it has to be statically analyzable.  Currently, ES2015 modules depends on MIME type checking if the imported file is a JavaScript module file, the whole module tree fails if any of them is not JavaScript. My thinking is we allow *some* non-JavaScript MIME types as a starter (e.g. `text/html`, or `text/css`) that can be imported, and grow types as needed.

-- 
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-322444196