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

@justinfagnani I wrote a rant on the old top-level await is a [footgun gist](https://gist.github.com/Rich-Harris/0b6f317657f5167663b493c722647221#gistcomment-2246480). Basically the idea of it is that the lack of top-level `await` simply promotes the same patterns but in a considerably worse way.

What'll simply happen is people will stop using all the features of ES modules properly and wind up re-creating AMD or something if they ever want to be able to use synchronous functions again e.g.:

```js
import someModule from "./someFile.js"

export default new Promise(resolve => {
    const { export1, export2 } = await someModule;
    const data = await fetch('data-file');
    return {
       otherExport1,
       otherExport2,
    }
}

```

So basically we manage to lose top-level names by not allowing top-level resource loading and gain precisely zero . Resource discovery should not be part of the ES module system period. Many file types may depend on loading arbitrary resources, there's already at least 3 things you can do to preload resources: use a service worker, use HTTP/2 push or just use a plain `<link rel="preload">`.

Regarding the last one, there's no way to register interest in resources without manually hoisting them to the top-level HTML and tools can only detect things like `fetch`/`import()` in certain trivial cases. What would be good is if modules supported `<link rel="preload">` behaviour out of the box maybe as a pragma e.g.:

```js
"preload resource1.txt as=fetch";
"preloadmodule child.js";

import foo from "foo.js";

const resource1 = await fetch('resource1.txt');

// ...
```

---

Frankly the lack of top-level await thus far has simply been a pain, I had a library (not a published one) where I wanted to export some synchronous functions but I needed to depend on a classic script. In order to do this I simply shamelessly used synchronous `XMLHttpRequest` because there's no good way to load a classic script as part of the dependency graph.

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