Re:Top-level await in JavaScript is a footgun
by nolanl on Wednesday September 14, 2016 @10:46AM
(#12497392)
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.
[ Parent
| on HN ]
Re:Top-level await in JavaScript is a footgun
by domenicd on Wednesday September 14, 2016 @11:24AM
(#12497871)
That's false. Module loading and execution are separate stages. The dependent modules would load before this await is ever reached.
Re:Top-level await in JavaScript is a footgun
by gavinpc on Wednesday September 14, 2016 @12:33PM
(#12498677)
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`.
Re:Top-level await in JavaScript is a footgun
by domenicd on Wednesday September 14, 2016 @12:38PM
(#12498734)
It would block dependent module execution, but not dependent module fetching, which is the actual expensive part.
Re:Top-level await in JavaScript is a footgun
by s_kilk on Wednesday September 14, 2016 @03:12PM
(#12500285)
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 :)
Re:Top-level await in JavaScript is a footgun
by domenicd on Wednesday September 14, 2016 @03:22PM
(#12500375)
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.