Quick triage note from our Reykjavik F2F: I placed this in the milestone for next week's telcon and marked this as urgent, as they've requested we get back to them in before 4 June.

From dynamic imports it is clear that the operation is async given that you must write await import() but @hober and I believe that developers will find it surprising that some of their declarative import statements are suddenly async as well.

Would it be possible to create new syntax? say await import { output } from './mymodule.js' or async import...? and maybe throw an error in the case it is used wrongly?

@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.

Don't you end up with the other problem as well, given that WASM modules are async, I would want to execute in parallel as much as possible and move away from declarative import statements and instead use Promise.all() or similar.

@kenchris The semantics of top-level await are based around these import statements executing in parallel, not in series, so it should be like using Promise.all (reference). import statements are very popular among JavaScript developers (currently in transpilers), and I think it'd be great if people could transparently use them with modules that use WebAssembly as well.

The current top-level await proposal is based on making normal import statements "just work": it avoids the potential problem of people natively using excessive dynamic import statements (which are less statically analyzable, affecting both bundlers and prefetching, even if both of those could resort to unsoundly special-case string arguments to import()), or excessively serializing (e.g., just await and not Promise.all).

@hober I've clarified further how the top-level await proposal maintains expectations of synchronous module loading behavior at https://github.com/tc39/proposal-top-level-await/blob/master/README.md#without-this-proposal-module-graph-execution-is-synchronous-does-this-proposal-maintain-developer-expectations-that-such-loading-be-synchronous . I'd be interested to hear your feedback.

Thanks for riding the TAG train, hope to see you soon again!