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

@AshleyScirra

> - it might actually help static analysis, since a static analyser might not know what the MIME type would be in advance
> - it makes the intent explicit, which helps you understand the code
> - it verifies the MIME type is the expected one, i.e. that you get an error if the MIME type accidentally changes, rather than silently switching the type of import.

I think these are all valid.  But I still see it's hard to be *generic* to every possible JavaScript type (core JavaScript ones + browser-implemented ones) or every MIME type, so we'd start from very limited set of types, probably.

Imagine:
```js
import doc from './foo.html' as DocumentFragment;  // okay, convert text/html to DocumentFragment
import cs from './foo.css' as CSSStylesheet;  // okay, text/css to CSSStyleSheet
import json from './foo.json' as Object;  // maybe okay...
import array from './foo-array.txt' as Array;  // maybe technically possible, but...
import png from './foo.png' as Image; // maybe...
import data from './foo.xls' as Blob;  // ???
import fromdata from './response.txt' as FormData;  // ???
```
I see `text/html` or `text/css` would be useful and they have use cases.  To implement, if we support N types, we would have to implement N paths to hook from JS module loader to parse and feed the decoded data into JS world.

Re dynamic imports: sometimes you would only have to import bootstrap code and other resources could be lazily loaded, in that case custom importer can be in the bootstrap code and be useful for processing lazily loaded contents.

```
// enables importing as HTMLModule, using library implementation in lib.js
import HTMLModule from '/lib.js'
import doc from '/module.html' as HTMLModule; // custom import
```

In the constraints of how today's ES2015 modules load, this seems difficult.

IIRC in the past [loader spec](https://whatwg.github.io/loader/) tried to have some filtering, though it seems it was removed.

Somewhat relevant issue there:
https://github.com/whatwg/loader/issues/87

The spec seems to have got stuck for long time, so we might not expect it to go anywhere.
Instead, let's make progress here.

@tilgovi 
> Browsers don't guess how to parse JavaScript based on MIME type or extension. They require type=module for ES modules, for instance.

Browsers *do* check MIME type before parsing JavaScript modules and rejects if they don't have valid JavaScript MIME types (see some comments above).  I tend to agree e.g. `<script type="module" src="./foo.html">` doesn't make sense, but other than that, what and why do you think a bad idea?

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