Advantages of Variant B
zenparsing opened this issue · 7 comments
I want to understand better the advantages being ascribed to variant B. I understand the general idea that more parallelism is good, and that Promise.all
ing async dependencies is generally preferred in async programming, but at the same time it's clear that there are some uncomfortable tradeoffs implied by variant B.
I'm having trouble thinking of realistic examples in this space; most of the top-level-await use case that I personally see are for simple node scripts or app-root modules, for which variant A works just as well.
Can someone think of a good concrete use case that can be used as a basis for discussion?
Thanks!
Here is a pretty simple example:
// app.mjs
import "./custom-element-1.mjs";
import "./custom-element-2.mjs";
// custom-element-1.mjs
const template = await (await fetch(new URL("./template-1.html", import.meta.url))).text();
customElements.define("custom-element-1", class extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' }).innerHTML = tempate;
}
});
// custom-element-2.mjs
const template = await (await fetch(new URL("./template-2.html", import.meta.url))).text();
customElements.define("custom-element-2", class extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' }).innerHTML = tempate;
}
});
In variant A, template-1 must be fully fetched before template-2 is fetched. In variant B, they can be fetched in parallel.
You may remember @Rich-Harris wrote a widely-read gist a couple years ago arguing against top-level await
. Just this morning he clarified that variant B resolves all(?) of his concerns, which were based on the assumption of variant A semantics.
Though it may not be exactly what you're asking, I think it's reasonable to include [disadvantages of variant A not shared by variant B] in the bucket of advantages we can ascribe to variant B.
I mean, parallel anything-awaitable. Network fetching is a prevalent example of such a proccess, but it's general, e.g. any web crypto operations or async parsing/decoding APIs or similar.
I think I got it: web application initialization will, in general, invoke various async APIs (e.g. fetching, crypto, or decoding APIs) which may be spread out across various modules. In order to minimize application startup time, the user would like execute all of those async operations in parallel.
Is that fair?
Yeah, that's the idea!
OK, I agree that variant A would be an "attractive nuisance" in those scenarios.