“ The Streams Standard was developed between 2014 and 2016 with an ambitious goal to provide "APIs for creating, composing, and consuming streams of data that map efficiently to low-level I/O primitives." Before Web streams, the web platform had no standard way to work with streaming data.”
This is what UDP is for. Everything actually has to be async all the way down and since it’s not, we’ll just completely reimplement the OS and network on top of itself and hey maybe when we’re done with that we can do it a third time to have the cloud of clouds.
The entire stack we’re using right down to the hardware is not fit for purpose and we’re burning our talent and money building these ever more brittle towering abstractions.
UDP is a protocol, not an API
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.
We're too busy building products while waiting for the perfect system to arrive.
I’m building everything from first principles, I’m not climbing the exponential curve with some billionaire that has to finance it.
I really doubt you are. you're not visiting the transistor shop every time you want to build a react component
Good thing your confidence is a soft requirement :)