Top-level await in JavaScript is a footgun
gist.github.com
Top-level await in JavaScript is a footgun
1–10 of 115 posts
Re: Top-level await in JavaScript is a footgun
#2> 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?
Re: Top-level await in JavaScript is a footgun
#3> 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?
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.
Re: Top-level await in JavaScript is a footgun
#4> 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?
Await essentially is blocking.
Re: Top-level await in JavaScript is a footgun
#5> 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?
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.
Re: Top-level await in JavaScript is a footgun
#6> 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?
`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.
Re: Top-level await in JavaScript is a footgun
#7He posted a follow-up superseding (or extending) the submitted post:
> A lot of people misunderstood Top-level await is a footgun, including me.
Re: Top-level await in JavaScript is a footgun
#8> 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?
`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.
Re: Top-level await in JavaScript is a footgun
#9I know that the argument that "silly developers shouldn't be allowed to do silly things" is a valid one, but I don't see a convincing argument that top level await is worse than what developers are currently doing, which is use synchronous functions to do IO at the top level.
If anything, top level async would be an improvement, as it would give developers no reason to do synchronous IO.
Edit: Additionally, ES6 modules are already imperative. There isn't any way to make them declarative.
Re: Top-level await in JavaScript is a footgun
#10Am I the only one who is happy using normal callbacks? I think they are the best representation of the asynchronous flow.