Intent to Ship: Top-level await

[Shu-yu Guo]

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]

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]

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]

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]

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]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEj67cmDuQZCnOzDUFX6_nNyDZ3nYQv8Kijint13q375-g%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dfdd%3D_85jke8Dvmtd2uG_0Wq02J1JhfeCnQuf6EjM2qoQ%40mail.gmail.com.