I don't know whether you want feedback from non-TAG members. I work on Chrome's WebSocket implementation. Some quick notes:

• It would have been more convenient if we had a websocket.ready property returning a Promise instead of the onopen event.
• The onerror event is useless -- it is the same as onclose with wasClean === false.
• The default of 'blob' instead of 'arraybuffer' for binaryType leads to unpleasant surprises.
• Lack of backpressure is unfortunate. If you can't keep up with the network you run out of CPU or RAM.
• WHATWG Stream support would be nice.

https://html.spec.whatwg.org/multipage/web-sockets.html

hey @ricea,

We looked through Web Sockets today...and unsurprisingly we agree with you!

Do you happen to know if changing the binaryType default would be web compatible?

Agree that retrofitting with Promises and Streams would be very helpful. @ylafon, @cynthia, @kenchris, @travisleithead and I support a ready Promise (as it doesn't appear sockets can be reopened). Do you have opinions about how the socket closing should be modeled? Also as a Promise?

Also, in your view, would adding a Streaming interface be the right place to introduce backpressure?

FYI, streams uses a getter for ready and not a method

It should be possible to replace

void send(ArrayBuffer data);
void send(ArrayBufferView data);

with void send(BufferSource data); which is a typedef for both. https://heycam.github.io/webidl/#BufferSource

@kenchris: Service Workers also use a getter: https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/ready

@slightlyoff Thanks for your response!

1.5% of messages received are Blobs (as opposed to 53% ArrayBuffers). Unfortunately I don't have data about how many blob-using connections set binaryType explicitly. We could collect more data but my gut feeling is that we can't change the default without breaking a lot of pages. There might be something clever we could do, but my mind is blank. At least we can tell that lots of people are finding the right button to push.

The reader and writer objects in the streams standard have a closed Promise which indicates when the stream is closed. I think this idea is almost directly applicable to the WebSocket API. Successful resolution means a clean close, rejection means some kind of error.

The streams interface is a really natural way to express backpressure. I've thought about having pause() and unpause() methods on the WebSocket object to let you control when the onmessage event is fired, but it's clunky by comparison.

Streams: We (some WebRTC spec folks) will start writing a streams extension for data channels soon. Since the API has been borrowed from Web Sockets, it should be easy to copy that work once we've done it.

https://github.com/w3c/webrtc-pc/issues/1732

Paris F2F: Looks like we've got some positive reactions here on the feedback. Since this was an unsolicited review request for HTML, I think the next step is to follow the WHATWG work mode for suggesting changes to Living Standards, and get an issue filed with the various feedback in it (or separate issues?), and then go about seeing if there is implementer interest, test changes, etc.

I'll see about filing this feedback soon-ish ;-)

Issues filed (at long last), and looking forward to implementers expressing interest in the same. This concludes our TAG review of the WebSockets section of HTML. Thanks for flying TAG!