Top-level await

[littledan]

Góðan dag TAG！

I'm requesting a TAG review of:

• Name: Top-level await
• Specification URL: https://tc39.github.io/proposal-top-level-await/
• Explainer, Requirements Doc, or Example code: https://github.com/tc39/proposal-top-level-await
• GitHub issues (if you prefer feedback filed there): https://github.com/tc39/proposal-top-level-await/issues
• Tests: none yet
• Primary contacts: @MylesBorins @littledan @guybedford

Further details (optional):

• Relevant time constraints or deadlines: We will discuss this proposal in the June 4 2019 TC39 meeting; TAG feedback before then would be appreciated (but it's understood that this request is at the last minute).
• [ x ] I have read and filled out the Self-Review Questionnare on Security and Privacy. There are no security/privacy issues, as this proposal only affects execution timing/coodination within JavaScript.
• [ x ] I have reviewed the TAG's API Design Principles

You should also know that...

The introduction of asynchronous modules may be interesting to the TAG, as modules can now take a broader role in asynchronous loading, including various kinds of loaded resources.

We'd prefer the TAG provide feedback as (please select one):

• [ x ] open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting

For background, see our explanation of how to write a good explainer.

[hober]

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.

[kenchris]

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?

[littledan]

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

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

[kenchris]

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.

[littledan]

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

[littledan]

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

[kenchris]

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