Re: [w3c/webcomponents] HTML, CSS, and JSON modules shouldn't solely rely on MIME type to change parsing behavior (#839)

> Oh wow, I didn't realize we were that close. So, my above would be replaced with `const { supportsBar } = await fetch("./config.json").then(x=>x.json())`? That really is the only use case I can think of. Maybe we don't need HTML/CSS/JSON modules after all?

Top-level await is absolutely not a replacement for CSS and HTML modules.

Wide-spread use of TLA will slow down module loading unacceptably. If every component in a large module graph of components uses TLA to load it's styles, then we get a waterfall of awaited fetches from deeper modules in the graph on up. If a module loads multiple resources, it has to take care to not have a waterfall locally. The ergonomics are terrible compared to `import`. TLA is dangerous enough that there is movement to ban them in ServiceWorker context, and I would expect linters and build tools to offer mode to ban them in regular modules as well.

Also, TLA+fetch doesn't offer the additional and extremely useful module semantics like deduplication and import maps. Imagine a CSS file that's loaded into every component in an app:

```js
const baseStyles = new CSSStyleSheet();
await baseStyles.replace(await (await fetch('../base/styles.css')).text());
```

First, that's absolutely horrific DX compared to `import baseStyles from '../base/styles.css' as css;`. Miss that first `await` and things break in a subtle way (the stylesheet updates in the background after the app logic has run, causing a flash of styling and a re-layout). Second, it doesn't benefit from deduplication at all. Every module that does this will cause a fetch of the base styles.

So now we have to add a cache, which further decreases the DX, so we add a wrapper library to load CSS and hope that _every developer in the world uses the same CSS loader so they use the same cache_. This screams for being a built-in due to all the pitfalls here.

Finally, this would leave the specific module semantics undefined and unimplemented, which leaves significant complexity to userland in the case of HTML modules, and precludes next steps in standardizing in-demand patterns around CSS modules (exporting class names, CSS references, potentially mixins, etc.).

-- 
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/839#issuecomment-555572825