Re: [w3ctag/design-reviews] Top-level await (#376)

@kenchris We considered this at https://github.com/tc39/proposal-top-level-await/pull/60 . There was a bit of excitement in the developer community about this alternative, which has a draft implementation in webpack by @sokra https://github.com/webpack/webpack/pull/9177 . I think this is an interesting alternative. Some rationale for the current proposal (in more depth at https://github.com/tc39/proposal-top-level-await/pull/60#issuecomment-473362344):

- The flip-side of "suddenly async" is the argument that we specifically should treat async modules as an implementation detail of the module itself: that modules *should* be able to introduce async work without requiring their dependencies to be updated.
- There was some concern that modules may introduce async work or async dependencies without realizing that this is a breaking change (which sort of boils down to the same concept).
- If we do require `import await` syntax, then people may start to use it defensively all over the ecosystem, to account for the possibility that their dependency becomes async later, defeating the purpose of introducing the additional syntax.

For example, WebAssembly modules are proposed to be async (to give time for parallelizable work when instantiating modules, today important in JSC, but possibly in the future in other engines). I believe it would be bad if there were breaking change when a module upgrades its implementation from JavaScript to WebAssembly, but if we adopt explicit `import await` syntax, this may be required for WebAssembly modules.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/376#issuecomment-495224285