Intent to Ship: Top-level await

281 views
Skip to first unread message

Shu-yu Guo

unread,
Oct 9, 2020, 4:10:58 PM10/9/20
to blink-dev

Contact emails

s...@chromium.org, cbr...@chromium.org


Explainer

https://v8.dev/features/top-level-await

https://github.com/tc39/proposal-top-level-await


Specification

https://tc39.es/proposal-top-level-await/


HTML integration:

https://github.com/whatwg/html/pull/4352

ServiceWorker integration:

https://github.com/w3c/ServiceWorker/pull/1444


Design docs

https://docs.google.com/document/d/15jxKo7kqj0bRHcnSmwjhj1XaWH1AXRDtYPiJHluCSiA/edit


Summary

Allow the `await` keyword at the top-level within JavaScript modules.


Blink component

Blink>JavaScript>Language


Search tags

top_level_await


TAG review

https://github.com/w3ctag/design-reviews/issues/376


TAG review status

Issues addressed


Risks


Interoperability and Compatibility

Stage 3 TC39 proposal, thus risk is low that others browsers will not implement it.



Gecko: Worth prototyping (https://mozilla.github.io/standards-positions/#top-level-await)


WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2020-September/031418.html)


Web developers: Positive


Activation

Not possible to polyfill.



Debuggability

Could cause timeouts and races in the hands of inexperienced developers.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes



Is this feature fully tested by web-platform-tests?

In test262: https://github.com/tc39/test262/tree/master/test/language/module-code/top-level-await


Changes to module script timing in WPT in various places. (See the TopLevelAwait virtual WPT suite.)


Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=9344


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5767881411264512

Kouhei Ueno

unread,
Oct 9, 2020, 10:20:22 PM10/9/20
to Shu-yu Guo, blink-dev
non-owner LGTM! Exciting work!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e-qQfgDVcb%3DyBYsjc41jA%2Bw4Hzw3kKKRHJj%2BYgJf23jZw%40mail.gmail.com.


--
kouhei

Yoav Weiss

unread,
Oct 10, 2020, 1:48:09 AM10/10/20
to Shu-yu Guo, blink-dev
Exciting work!

I'm continuously concerned about the lack of reasonable content negotiation for JS features, although this is not something unique to this feature.
I'm assuming that transpilers will support serving this only to supported browsers using the browser and version information in the UA string?
How do we expect developer adoption to look like?



Debuggability

Could cause timeouts and races in the hands of inexperienced developers.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes



Is this feature fully tested by web-platform-tests?

In test262: https://github.com/tc39/test262/tree/master/test/language/module-code/top-level-await


Changes to module script timing in WPT in various places. (See the TopLevelAwait virtual WPT suite.)


Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=9344


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5767881411264512

--

Shu-yu Guo

unread,
Oct 12, 2020, 12:10:56 PM10/12/20
to Yoav Weiss, blink-dev
I'm no expert on transpilers, but I don't think UA strings come into it. The developer chooses the featureset that the downleveled output should target at build time. The minimum target for TLA seems to be support for async/await, in ES2017.
  • TypeScript will allow TLA under a certain set of conditions. I'm not sure how esnext module output downleveling works (maybe it's native). For SystemJS, I assume that module scripts with TLA will be transformed to an immediately invoked async function that the SystemJS module loader understands.
  • Babel hooks into module bundlers like webpack. Webpack's compilation of TLA looks like it is also to an immediately invoked async function.
Shipping ES module natively on the web is still low. I've seen much anecdotal evidence of developer excitement for this, so I reckon there will be significant adoption via transpilers like TypeScript and module bundlers like webpack.

Mathieu Hofman

unread,
Oct 12, 2020, 2:40:08 PM10/12/20
to blink-dev, Shu-yu Guo, blink-dev, yo...@yoav.ws

I believe the question at hand is how to use new syntactic feature of the language such as TLA without transpiling for browsers that implement those features. Unlike API additions that can be dynamically feature tested, new syntax would cause parse errors on older browsers. Currently you can use the module/nomodule paradigm to target a certain set of language features that are known to be supported if the browser supports ES modules. Any newer features need to be transpiled as I don't believe there is any way to do content negotiation, or we have to rely on somewhat brittle user agent sniffing at the server, which is getting removed. This is an ecosystem problem that is in need of some standardized solution. Is there any ideas or proposals on how to fix this problem? Maybe an extension of module maps?

Yoav Weiss

unread,
Oct 13, 2020, 2:02:25 AM10/13/20
to Mathieu Hofman, blink-dev, Shu-yu Guo
On Mon, Oct 12, 2020 at 8:37 PM Mathieu Hofman <mathieu.h...@gmail.com> wrote:

I believe the question at hand is how to use new syntactic feature of the language such as TLA without transpiling for browsers that implement those features.

That's indeed the question - can developers use this feature in the browser before it is ubiquitously supported? If so, how?

Unlike API additions that can be dynamically feature tested, new syntax would cause parse errors on older browsers. Currently you can use the module/nomodule paradigm to target a certain set of language features that are known to be supported if the browser supports ES modules. Any newer features need to be transpiled as I don't believe there is any way to do content negotiation, or we have to rely on somewhat brittle user agent sniffing at the server, which is getting removed.

Just to clarify, the browser brand and version are not planned to be removed from the User-Agent string, and are exposed by default with User-Agent Client Hints.

Shu-yu Guo

unread,
Oct 13, 2020, 11:59:12 AM10/13/20
to Yoav Weiss, Mathieu Hofman, blink-dev
Thank you for the clarification. The way to use new TLA without ubiquitous browser support remains by using transpilers. This is true of all other JS syntax features as well -- since polyfilling isn't possible, the only way to use them in unsupported browsers is via transpilation.

Finer-grained feature detection for syntax features has its own tradeoffs. Discussion about that is probably best had in another thread, however.


Yoav Weiss

unread,
Oct 14, 2020, 4:55:25 PM10/14/20
to Shu-yu Guo, Mathieu Hofman, blink-dev
I agree this is true for other new features as well (and as such, not a blocker for TLA), but seems like we need better developer advice than "dynamically serve your JS using browser+version based content negotiation" when delivering new language features to users.

But as I said, this is a broader issue.

LGTM1

Mike West

unread,
Oct 15, 2020, 5:08:41 AM10/15/20
to Yoav Weiss, Shu-yu Guo, Mathieu Hofman, blink-dev
LGTM2. The question of content-negotiation is indeed interesting, but shouldn't block shipping this specific feature any more than any other syntax (arrow function expression, etc.).

-mike


Chris Harrelson

unread,
Oct 15, 2020, 11:04:32 AM10/15/20
to Mike West, Yoav Weiss, Shu-yu Guo, Mathieu Hofman, blink-dev
Reply all
Reply to author
Forward
0 new messages