Logistics

• Date & Time: Wednesday 4th June at 16:30 CEST (local time)
• URL: https://meet.jit.si/WEH2025-AsyncContext
• Notes: https://github.com/Igalia/webengineshackfest/wiki/2025-AsyncContext:-trimming-down-the-web-integration
• Room: JS

Facilitator(s)

@nicolo-ribaudo (Igalia)

Summary

The AsyncContext TC39 proposal gives a way to implicitly propagate some context through async operations. This is especially useful for front-end frameworks and performance tracing libraries, which do not want their users to have to manually do it, keeping how this propagation works as an internal implementation detail of the framework/library.

While some of this propagation can be done in userland by monkey-patching built-in async APIs (for example, by replacing window.setTimeout with a version that propagates the context to the callback), it cannot be done in all cases and most importantly it cannot be done when it comes to async/await, since it's syntax.

The proposal thus started with async/await and promises support, to then expand to cover as many async APIs as possible on the web platform. This is what is maximally useful for JavaScript developers, but it also has a high implementation complexity for browser developers leading them to push back on the proposal. How can we simplify the web integration, to find the right balance between utility and implementability?

Type

Onsite

Other comments

There will be a similar discussion at the TC39 meeting before the WEH, but with a different audience.