[mlhpdx]

True. But it’s also true that trying to shoehorn every use case into TCP streams is counter productive.

A stream API can layer over UDP as well (reading in order of arrival with packet level framing), but such a stream would a bit weird and incompatible with many stream consumers (e.g. [de]compression). A UDP API is simpler and more naturally event (packet) oriented. The concepts don’t mix well.

Still, it would be nice if they browser supported a UDP API instead of the weird and heavy DTLS and QUIC immitations.

[kaoD]

TCP or UDP are orthogonal to this, so the original comment feels like a non sequitur. These streams are not network streams and could be a file, chunks of procedural audio, or whatever.

[mlhpdx]

I agree, the stream concept should be (and is) very general and ideally cover all these cases - any “bytes producing” source.

I was trying to be open minded about that and conceive a stream API over a UDP socket. It’d work IMHO, but be a little odd compared to an event-like API.

[drysart]

The browser does have a UDP data stream available for applications to send arbitrary bytes over UDP; it's part of WebRTC.

[mlhpdx]

While Web RTC is built on UDP, it does not allow sending arbitrary UDP. It's DTLS, perhaps encapsulating SCTP, and DCEP.