Skip to content

2025 AsyncContext: trimming down the web integration

Jump to bottom Edit New page
Manuel Rego edited this page Jun 12, 2025 · 1 revision

WEH 2025 - AsyncContext: trimming down the web integration

Introduction

  • Nic giving an introduction to the proposal (https://github.com/tc39/proposal-async-context)
  • Got feedback from some browsers that this proposal is very difficult for them to propogate the context through all web platform async APIs. They argue it is not worth it for all APIs.
  • Canva mentioned that it would be cool to propogate context on APIs like ResizeObserver
  • MutationObserver can lead to cycle with recompute -> restyle -> relayout -> ...
  • Going through specific APIs
    • await (propogate context), impossible to polyfill due to syntax (requires transpilation)
    • setTimeout and similar schedulers (propogate context), easy to polyfill
    • addEventListener (suggesting drop context), easy or impossible to polyfill depending on event. Worth noting most frameworks have their own event implementation meaning they can polyfill it if they'd like.
    • Stream underlying source/sink/transformer (propogate context), very difficult to polyfill and sometimes impossible
    • Observers (mutation, resize, intersection) (suggesting drop context), impossible to propogate
  • Fallback registration-time idea (suggesting dropping)
    • Difficult to implement a polyfill but easy to wrap specific APIs
  • What does "dropping support" actually mean
    • sync callbacks: same async context as for its last JS caller
    • async callbacks: context is "lost" and runs in root context
  • Ad-hoc integration for specific use cases
    • If addEventListener doesn't have general support, we'd still need some ad-hoc to solve a few conrete cases

Q&A

  • Open to Q&A, what can we sacrifice to simplify the web integration?
    • Many things cannot be added incrementally
    • Scott: message and postMessage are very important cases for us. React uses it for scheduling
    • Nic: Do any frameworks besides React do this?
    • Steve: It's pretty common, Jasmine does this as well
    • Andreu: We heard feedback that if we do not propogate via addEventListner, tracing frameworks will likely monkey patch all events in order to preserve context
    • Steve: This underlines the importance of getting the initial design as right as possible
    • Steve: Proposing that we could skip parallel tasks and just specify that anywhere in the spec that says "queue a task" means it will maintain the same context as the task that queued it
  • Nic: Maybe we can switch the discussion and focus the last 30 minutes on whsere we can move the "right balance" arrow to get the proposal unstuck
    • We've talked about a few special cases like postMessage, but what do we think is the left-most point of the arrow on the slides (most developer needs) that all browers would be willing to implement.
  • Nic: Does anyone have opinions on other events we haven't talked about yet? For example how difficult or simple it would be to propogate from streams
  • How would new API authors figure out which propogation mechanism to use?
    • Nic: I think not propogating is a good default for new APIs as they can opt-in to a propogation mechanism later
    • Luca: The problem with that is that for the tracing use case you want the propogation to happen without adding a bunch of code. Users will have to wrap every applicable event on the web platform. Concerned that libraries will, if propogation is not default, wrapp all events
    • Nic: Just to point out that they would likely specify specific properties and not leak all properties from all events
    • Andreu: The previous session was about signals and observables and it brought up the idea that maybe in the future you could treat all events as variables that return a promise
    • Nic: There has been a proposal in the DOM spec that if you use addEventListener for a one time event, it just returns a promise. This only solves things for one time events though like load
    • Steve: You mentioned the idea of adding a property to the event in event listers but if framework authors patch
    • discussion about adding a new property to event listener events
    • Chengzhong: This seems better than forcing tracing libraries to wrap all user code
    • Steve: This seems dangerous
    • Andreu: Could we try to drive a conclusion?
    • Steve: We haven't heard from as many implementors as we were hoping
    • Smaug: If we remove too much does the proposal lose some of it's value?
    • discussion around weak pointers and the async context map
    • Nic: We had earlier discussion about whether or not they should be weakmaps

https://www.webengineshackfest.org/

Add a custom sidebar
Clone this wiki locally