Hacker News Reader

Comment by rco8786 | Hacker News Reader

> Even assuming all goes well, you've prevented yourself from doing any other work, like rendering views that don't depend on that data.

Is that right? `await` is non-blocking, no?

View on HN

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.

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.

`await` allows the event loop/job queue to run while waiting. However, while using `import` declarations, your module will not run until all imports have completed; this means that your module will be suspended while the dependency awaits.

If your app is shipped as a single bundle this means your entry point would be unable to run anything while dependencies are awaiting if you use `import` declarations. If your app places runtime dependent imports into a dynamic import like using `import()` as a function, it would not be suspended while waiting.

Exactly correct. But note that

> your entry point would be unable to run anything while dependencies are awaiting

is very different from the situation with synchronous I/O (in a single-threaded environment).

With sync I/O, not only is your entry point unable to do anything (which is what it chose to do, by using `import` instead of `import()`), your entire app is unable to do anything! So other entry points are also blocked.

Even worse, since sync I/O blocks the event loop, it prevents the user from interacting with your web page or Node app---e.g. scrolling, clicking links, pressing Ctrl+C to exit, and so on.

It's not so much about blocking as it is about delaying the module waterfall. E.g. a module that did `await new Promise(_ => setTimeout(_, 5000))` at the top would prevent any of its dependents from being loaded for 5 seconds.

That's false. Module loading and execution are separate stages. The dependent modules would load before this await is ever reached.

Wait... so the OP's premise is completely wrong? Doesn't the body of a module have to complete before dependent modules will execute their bodies?

In other words, if you put

    for (let i = 0; i < 10e8; i++)
        // blah

in the body of a module, wouldn't that block dependent modules for the duration of the loop?

Would top-level await be different?

edit The premise, as I understand it, is that the module itself is treated as the "currently-executing method" for the purpose of the `await`.

It would block dependent module execution, but not dependent module fetching, which is the actual expensive part.

It's kinda funny how the semantics of this thing are so non-obvious and nuanced, that it takes so much effort to explain to people how it works :)

It's not that complicated; unfortunately a lot of FUD has been spread about alternate models based on misconceptions, which definitely makes it tricky to explain because you have to overcome that FUD.

Sounds like I misunderstood. Thanks for the correction!

`await` will "block" the current method but the current calling method will continue executing unless that method calls await itself (and so on). You can perform whatever other work needs to happen that doesn't require on the data. It's just a matter of having the right architecture in place that doesn't just waits for the request to finish before doing additional work.

Await essentially is blocking.

Reply on news.ycombinator.com