Skip to content

2025 TC39 proposals and integration with the web platform

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

WEH 2025 - TC39 proposals and integration with the web platform

Notes:

  • https://github.com/tc39/proposals
  • New JS features are better if they work well with the web platform.
    • For example, import attributes are defined in tc39 but only useful if used by resources in the web platform
    • Promises are another example, made more useful by the web platform
    • There is no process for working between groups
  • Instead of just talking about standards processes, let's look at concrete tc39 proposals
  • Andreu: Some proposals like AsyncContext (https://github.com/tc39/proposal-async-context) it is vital to have a good web integration from the beginning, other proposals like structuredClone are maybe ok if they are added in the future
  • Anne: Less concered with breaking than missed integration points
  • Jon: seems not only champions need to do a better job at integration, implementors also lack communications, wondering if multiple catches in standards bodies would help avoiding missing opportunites
  • Chengzhong: we don't have hard requirement on this during stage 2 in TC39
  • Anne: I think there is a sentence in there https://tc39.es/process-document/ not hard block though
  • Jon: wondering what could be done to avoid the missing opportunity in WebAssembly exception vs Error.isError
  • Luca: looking at Dispose. Should unconsumed Response body be cleaned up by Dispose?
    • Would be good to file an issue for this. Specifically fetch having a dispose method that would propogate down to the body: https://github.com/whatwg/fetch/issues/1833
    • Luca: any other APIs that have a close method that need to implement Dispose? ReadableStream, WritableStream, AbortController, EventSource, WebSockets Response and Request
    • Anne: Blob, some file system APIs
    • Luca: Deno has added dispose methods on a lot of APIs already
    • Anne:
    • Leo: WebGPU
    • Chengzhong: There is an open issue in node about adding disposable to event listeners (https://github.com/nodejs/node/issues/58383)
    • Luca: For websockets, you could have a DisposableStack on a class that contains websockets so when the class is cleaned, the websocket is cleaned up too. Symbol dispose is useful even outside of using declarations
    • Anne: It does seem like there is some tension between signals and dispose-like. If you add an event to a DisposableStack should it still accept AbortSignals?
    • Nic: They have different cases, AbortSignals are great for giving to other users where as using is more local
    • Luca: AbortSignals are different, you can abort before the promise is resolved but you can't dispose before that.
    • Luca: sounds like if you already have an abort controller you could just register it and reuse for dispose (?)
    • Temporal (https://github.com/tc39/proposal-temporal)
      • Nic: Currently the only web integration for Temporal is inside structuredClone
      • Currently input type date could probably support a temporal based API, is anyone working on that?
      • Philip: StructuredClone is also what we consider the bare minimum. There is a current issue for supporting Temporal in the web platform (https://github.com/tc39/proposal-temporal/issues/3075)
      • Nic: setTimeout duration
      • Luca: AbortSignal timeout duration. Really any APIs that support duration
      • Anne: Is the argument to setTimeout typed at the moment
      • Andreu: It's an int
      • Nic: Process wise, do you consider web integration a blocker for stage 4?
      • Philip: I was not considering it a blocker for stage 4
      • Anne: Agreed but maybe the idl infrastructure should be there just so people can adopt it
    • Array Buffers
      • Luca: There are two proposals here. One has already landed (resizeable array buffers https://github.com/tc39/proposal-resizablearraybuffer) and one is stage 2.7 (immutable array buffers https://github.com/tc39/proposal-immutable-arraybuffer)
      • Luca: Is it worth mentioning in web specs that clone array buffers that they may now be passed in immutable array buffers
      • Andreu: Is Resizable ArrayBuffer integrated into WebIDL? [Anne says yes.] Should Resizable and Immutable WebIDL extended attributes be combined? Identify various categories of APIs that use the ArrayBuffer in different ways, and have extended attributes that handle resizable and immutable in appropriate ways.
      • Luca: There are broadly three classes here, read only, mutable and then everything else
      • Andreu: leave that to the Web IDL instead of in the API semantics. Thinking about e.g. WebIDL binding codegen in browsers. If a mutable array buffer is passed, copy the data in the bindings; or with an immutable ArrayBuffer, just pass the pointer-and-length to the API implementation (and make sure the ArrayBuffer isn't GC'd while it's being used). The WebIDL binding takes care of that, and the spec text / native browser implementation only deals with a memory slice that is guaranteed not to be mutated in between.
      • Anne: was brought up before and we just ... and made it copy everywhere. Would be nice if the semantics is in the binding. make it happen.
    • Luca: Would the new getOrInsert make sense for webidl? https://github.com/tc39/proposal-upsert
    • ? & Anne: this would make sense for search params
    • Leo: upsert would be more useful
    • Luca: yes, when there are multiple values for the same key

https://www.webengineshackfest.org/

Add a custom sidebar
Clone this wiki locally