WebSocketStream: Stream-based backpressure-supporting API for the WebSocket protocol

[ricea]

WebKittens

@annevk

Title of the spec

WebSocketStream

URL to the spec

https://whatpr.org/websockets/48.html#the-websocketstream-interface

URL to the spec's repository

https://github.com/whatwg/websockets

Issue Tracker URL

No response

Explainer URL

https://github.com/ricea/websocketstream-explainer/blob/master/README.md

TAG Design Review URL

https://github.com/w3ctag/design-reviews/issues/394

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/970

WebKit Bugzilla URL

No response

Radar URL

No response

Description

WebSocketStream is a new API for the WebSocket protocol that enables backpressure by integrating with Streams. The benefits are better behaviour when one side cannot keep up with the data rate, and a more modern API.

[annevk]

Overall this looks good. However, do you have some data that supports investing more in WebSocket? Now there's WebTransport and streaming in fetch it's becoming kind-of niche so it would be good to know this effort is worth the ongoing maintenance cost.

[ricea]

Chrome sees WebSockets used on 10% of page loads: https://chromestatus.com/metrics/feature/timeline/popularity/1149

For comparison WebTransport is still at 0.002% of page loads: https://chromestatus.com/metrics/feature/timeline/popularity/3472

I think that's an indication of the time it takes to ramp up support for a new protocol. WebTransport can do a lot more than WebSocket, but it will be years before it is as easy to deploy. WebTransport is a powerful investment for the future, whereas WebSocketStream is a practical investment for the present.

Most (all?) major server-side environments have mature, solid WebSocket support.

WebSockets are widely supported by CDNs: https://www.cdnplanet.com/guides/websockets/#:~:text=without%20an%20origin%3F-,CDN%20comparison,-Yes

Interest in WebSockets is growing for some reason: https://insights.stackoverflow.com/trends?tags=websocket

Page load percentages for some vaguely related technologies:

• Fetch: 56%; https://chromestatus.com/metrics/feature/timeline/popularity/675
• Fetch response streaming: 12%; https://chromestatus.com/metrics/feature/timeline/popularity/676
• Fetch upload streaming: 0.002%; https://chromestatus.com/metrics/feature/timeline/popularity/3326
• EventSource: 1%; https://chromestatus.com/metrics/feature/timeline/popularity/1479
• RTCPeerConnection: 6%; https://chromestatus.com/metrics/feature/timeline/popularity/3453

[annevk]

Thanks! I should have specifically asked for web developer interest as we're curious what adoption might look like. Per https://chromestatus.com/feature/5189728691290112 there's no indication this is desired?

And per https://issues.chromium.org/issues/41470216 the little feedback that was given seemed to desire a fix for backpressure on top of the existing API?

[tomayac]

For developer interest:

• The Deno runtime has implemented the WebSocketStream interface.
• A polyfill to use the API in current browsers exists.