81–90 of 115 posts
Yes, top-level await sounds silly. It would freeze the entire app... You couldn't even render a loading progress bar - It would defeat the whole point of loading modules asynchronously.
incorrect. `await` is a reserved word only in async contexts, the UI thread event loop still runs while `await`ing.
Earlier quoted context omitted.
Well, I was happy using normal callbacks, but then promises made me a bit happier and now I even happier with async/await. You can definitely write clean code with only callbacks, but one has to be pretty careful if there are many nested asynchronous actions. Promises and await make that code very much clearer.
And then as you use promise based code more and more (including with async/await), you eventually come to realize that while it looked good at first, its deeply, deeply flawed, and is at best a stepping stone to Observables :)
Here is the proposal: https://github.com/tc39/proposal-observable
Earlier quoted context omitted.
This is probably the bigger deal. It means that not only is top-level await dangerous , it's potentially destructive even when used correctly.
It's also based on yet further misunderstandings (in this case not understanding the ability of engines to do speculative fetches).
When you talk about speculative fetches, are you suggesting that engines would guess at which modules were going to be imperatively imported before actually running the code? That doesn't seem like a general solution, or even a particularly desirable one, but I'm interested to learn what you're referring to.
I agree that top-level await is weird. But the bigger issue is that importing stuff shouldn't be an imperative statement ("load the code at such-and-such address"). That's marrying the language to irrelevant details of how it's parsed and executed. Instead, import should be a static construct that can get special treatment from interpreters and compilers. Header files in C are another instance of the same mistake ("l…
> but a proper module system like Java's is always Java has a package system not a module system.The difference is important because Java might introduce a module system in the future. And Java isn't built around async programming by default, even loading a jar is synchronous.
Earlier quoted context omitted.
Thanks for clarifying the point re module evaluation not being sequential – that would seem to break some fundamental guarantees about execution order, but I guess that's a separate discussion. The point stands that your entry point has to wait until each of its dependencies and each of their dependencies (&c) have finished before your app can start, and it unavoidably slows down module loading. > This is basically t…
> The point stands that your entry point has to wait until each of its dependencies and each of their dependencies (&c) have finished before your app can start, and it unavoidably slows down module loading. That's true regardless of whether you use top-level await or not.
Meanwhile, you still have to do more work to load the app in the first place (https://gist.github.com/Rich-Harris/41e8ccc755ea232a5e7b88de...).
I'm genuinely curious about the statement that modules can execute concurrently, and what that means for predictability. Jotted down some thoughts here: https://gist.github.com/Rich-Harris/9a270920e203e6df9477ca02...
Earlier quoted context omitted.
incorrect. `await` is a reserved word only in async contexts, the UI thread event loop still runs while `await`ing.
If you run an await as a first thing in the top-level, you have nothing in the event loop to run. Await blocks everything after itself, and that is very dangerous if done on the top-level.
Earlier quoted context omitted.
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 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-execut…
It would block dependent module execution , but not dependent module fetching , which is the actual expensive part.
Earlier quoted context omitted.
It's also based on yet further misunderstandings (in this case not understanding the ability of engines to do speculative fetches).
Domenic, I do wish you'd at least try to engage fruitfully in these discussions without resorting to your usual snark and condescension. When you talk about speculative fetches, are you suggesting that engines would guess at which modules were going to be imperatively imported before actually running the code? That doesn't seem like a general solution, or even a particularly desirable one, but I'm interested to learn…
Yes, that is indeed what I am referring to, as engines already do for HTML.
Earlier quoted context omitted.
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 :)
Earlier quoted context omitted.
Whether or not it's a module or something else being awaited isn't the problem. The issue that if your app.js (or whatever) has dependencies on modules with top-level awaits, however far removed, it can't execute until they're done. In other words top-level await essentially blocks your entire app. Using await inside an explicitly async function is great, because it only blocks code inside that function – the effects…
Now we just need asynchronous imports and all is well again. I can't even tell whether I'm being sarcastic or not.