Intent to Implement: Top Level Await

110 views
Skip to first unread message

Joshua Litt

unread,
Aug 7, 2019, 2:39:21 PM8/7/19
to blink-dev, v8-u...@googlegroups.com
joshu...@chromium.org https://github.com/tc39/proposal-top-level-await Specification: https://tc39.es/proposal-top-level-await/ https://docs.google.com/document/d/15jxKo7kqj0bRHcnSmwjhj1XaWH1AXRDtYPiJHluCSiA/edit?usp=sharing Allow keyword 'await' at the module level. Allows more seamless integration of async calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.
Stage 3 TC39 proposal, thus risk is low that others browsers will not implement it. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Not possible to polyfill.
Could cause timeouts and races in the hands of inexperienced developers. Yes No Tests are WIP. https://chromestatus.com/feature/5767881411264512

Yoav Weiss

unread,
Aug 8, 2019, 7:38:08 AM8/8/19
to Joshua Litt, blink-dev, v8-users
On Wed, Aug 7, 2019 at 8:39 PM Joshua Litt <joshu...@chromium.org> wrote:
joshu...@chromium.org https://github.com/tc39/proposal-top-level-await Specification: https://tc39.es/proposal-top-level-await/ https://docs.google.com/document/d/15jxKo7kqj0bRHcnSmwjhj1XaWH1AXRDtYPiJHluCSiA/edit?usp=sharing Allow keyword 'await' at the module level. Allows more seamless integration of async calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.
Stage 3 TC39 proposal, thus risk is low that others browsers will not implement it. Firefox: No public signals Edge: No public signals Safari: No public signals

More of a TC39 process question, but aren't there clear signals from other vendors by the time the proposal is at stage 3?
 
Web developers: No signals

Searching Twitter brought up e.g. https://twitter.com/bitandbang/status/1136549425659162624 (with 100+ RTs and 300+ likes) indicating that there is at least some developer enthusiasm towards this feature.

Not possible to polyfill.
Could cause timeouts and races in the hands of inexperienced developers. Yes No Tests are WIP. https://chromestatus.com/feature/5767881411264512

--
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/CANGvXFho4AE_YzscsMX2TBgy%3DmWEJQ9sv1dfmrH4SPVjdV6ogA%40mail.gmail.com.

mbo...@google.com

unread,
Aug 8, 2019, 12:27:35 PM8/8/19
to blink-dev, joshu...@chromium.org, v8-u...@googlegroups.com
More of a TC39 process question, but aren't there clear signals from other vendors by the time the proposal is at stage 3?

At the May TC39 meeting we had interest expressed verbally from Firefox, Safari, and Moddable in implementing this feature. There is a mozilla tracking issue.

The tweet I did about the proposal reaching Stage-2 had 50k impressions --> https://twitter.com/MylesBorins/status/999005736914087936. I've also had a couple threads with reasonable engagement asking developers what they would use the feature for.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Joshua Litt

unread,
Aug 8, 2019, 12:42:18 PM8/8/19
to mbo...@google.com, blink-dev, v8-u...@googlegroups.com
Apologies, I actually meant this as a stub entry. I intended to flesh it out a bit more when TLA got closer to actually landing in V8. 'No public signals' was just unfortunately the default for those options.

Adam Klein

unread,
Aug 8, 2019, 3:07:21 PM8/8/19
to Yoav Weiss, Joshua Litt, blink-dev, v8-users
On Thu, Aug 8, 2019 at 4:38 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Aug 7, 2019 at 8:39 PM Joshua Litt <joshu...@chromium.org> wrote:
joshu...@chromium.org https://github.com/tc39/proposal-top-level-await Specification: https://tc39.es/proposal-top-level-await/ https://docs.google.com/document/d/15jxKo7kqj0bRHcnSmwjhj1XaWH1AXRDtYPiJHluCSiA/edit?usp=sharing Allow keyword 'await' at the module level. Allows more seamless integration of async calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.
Stage 3 TC39 proposal, thus risk is low that others browsers will not implement it. Firefox: No public signals Edge: No public signals Safari: No public signals

More of a TC39 process question, but aren't there clear signals from other vendors by the time the proposal is at stage 3? 

Stage 3 means that there's consensus from the committee at large (which includes other vendors) that it's ready for implementation, and that we expect it to make its way into the ES spec once it reaches Stage 4. But "consensus" and "support" aren't necessarily the same thing. Similarly, consensus and implementation aren't the same thing.

So your question leads to a Blink Intents process question: is there good guidance on what sort of data is good input to these fields?

Web developers: No signals

Searching Twitter brought up e.g. https://twitter.com/bitandbang/status/1136549425659162624 (with 100+ RTs and 300+ likes) indicating that there is at least some developer enthusiasm towards this feature.

Not possible to polyfill.
Could cause timeouts and races in the hands of inexperienced developers. Yes No Tests are WIP. https://chromestatus.com/feature/5767881411264512

--
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/CANGvXFho4AE_YzscsMX2TBgy%3DmWEJQ9sv1dfmrH4SPVjdV6ogA%40mail.gmail.com.

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

Yoav Weiss

unread,
Aug 9, 2019, 4:08:36 AM8/9/19
to Adam Klein, Joshua Litt, blink-dev, v8-users
On Thu, Aug 8, 2019 at 9:07 PM Adam Klein <ad...@chromium.org> wrote:
On Thu, Aug 8, 2019 at 4:38 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Aug 7, 2019 at 8:39 PM Joshua Litt <joshu...@chromium.org> wrote:
joshu...@chromium.org https://github.com/tc39/proposal-top-level-await Specification: https://tc39.es/proposal-top-level-await/ https://docs.google.com/document/d/15jxKo7kqj0bRHcnSmwjhj1XaWH1AXRDtYPiJHluCSiA/edit?usp=sharing Allow keyword 'await' at the module level. Allows more seamless integration of async calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.
Stage 3 TC39 proposal, thus risk is low that others browsers will not implement it. Firefox: No public signals Edge: No public signals Safari: No public signals

More of a TC39 process question, but aren't there clear signals from other vendors by the time the proposal is at stage 3? 

Stage 3 means that there's consensus from the committee at large (which includes other vendors) that it's ready for implementation, and that we expect it to make its way into the ES spec once it reaches Stage 4. But "consensus" and "support" aren't necessarily the same thing. Similarly, consensus and implementation aren't the same thing.

So your question leads to a Blink Intents process question: is there good guidance on what sort of data is good input to these fields?

Good input would be (in ascending order):
  • Lack of objection in public discussions
  • Enthusiasm about the feature in public discussions
  • Clear public commitment to implement (e.g. on Github or mailing lists). 
    • Mozilla are using their standards position repo to provide their position for web exposed features, but I'm not sure if ES features are also included there
  • Active implementation effort
  • Shipping features

Anne van Kesteren

unread,
Aug 9, 2019, 7:16:50 AM8/9/19
to Yoav Weiss, Adam Klein, Joshua Litt, blink-dev, v8-users
On Fri, Aug 9, 2019 at 10:08 AM Yoav Weiss <yo...@yoav.ws> wrote:
> Mozilla are using their standards position repo to provide their position for web exposed features, but I'm not sure if ES features are also included there

Mozilla is supportive of shipping stage 3 TC39 proposals. Some TC39
proposals are discussed on standards-positions before that stage, if
they could use wider input (e.g., Builtin Modules).
Reply all
Reply to author
Forward
0 new messages