So you're ok that your app waits on module dependencies, but data dependencies it should not?

But my app doesn't wait on module dependencies - the code is bundled. It does wait on code parsing time (which no, I don't consider ideal) but that's a far cry from waiting on an async data download operation.

As far as I'm concerned, an explicit call to `ModuleB.loadData()` is far better than having it happen as part of module loading, without me necessarily being aware of it. Right now, module loading is assured to be synchronous, and losing that certainty seems like a bad idea to me.

If you're going to perpetually use scripts then this conversation doesn't apply to your. Your script bundles will continue to work as they already do.

But your entire app wouldn't be held up! Only that subgraph.

So in the future, you'll have to split up your app into multiple entry points specifically to contain the effects of top-level await spilling out? Sounds like using explicitly async functions would be a far more understandable and maintainable approach.

So the argument is that the bad-effects of top-level await are viral. One bad apple in the app entry point's dependency graph stalls evaluation of the main entry point. And to mitigate this risk, you have to segregate out sub-graphs that you safely load via imperative import().

Doesn't the same risk apply if one of the modules in the graph declaratively imports a module hosted on a slow external CDN?

It does, yes. Using a slow, external CDN is a bad idea for exactly that reason.