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.
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.
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.
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.
The browser does have a UDP data stream available for applications to send arbitrary bytes over UDP; it's part of WebRTC.