5 ms·

Thanks for clarifying the point re module evaluation not being sequential – that would seem to break some fundamental guarantees about execution order, but I gu

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 the same old argument against `await` itself: that it allows developers to write bad code It magnifies the effect to a degree that isn't immediately obvious – hence footgun. Users are the ones who will suffer, therefore it's right that we exercise some restraint.

domenicd 10y ago
> 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.
- rich_harris 10y ago
  It's true that your dependencies have to execute, obviously, but it's much easier to slow things down if you can block while asynchronous work happens. Right now that's not possible. Meanwhile, you still have to do more work to load the app in the first place (https://gist.github.com/Rich-Harris/41e8ccc755ea232a5e7b88dee118bcf5 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/9a270920e203e6df9477ca02318fb640 https://gist.github.com/Rich-Harris/9a270920e203e6df9477ca02...