Hacker News Reader

Comment by rich_harris | Hacker News Reader

An async function is non-blocking. await is blocking within the async function. Top-level await basically boils down to a proposal to wrap your entire app inside an async function.

View on HN

That's false. It wraps each individual module within an async function. They can each proceed concurrently. (And all of them proceed after any `import`ed modules load.)

But any module with a dependency on a module with top-level await will have to wait for that dependency. As will anything depending on that.

It's not difficult to imagine some code nested deep in some NPM module completely changing the load behaviour of your app without you knowing.

Yes. Let's rephrase that first sentence.

"Any module with a dependency on data that it needs to execute will have to wait for that data before it executes."

That's a good thing.

Is it a good thing for your entire app to be held up by any component that needs to load data? I'm sceptical.

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.

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.

Reply on news.ycombinator.com