The Streams API is a nice method for interacting with potentially infinite streams of data in the Browser. ReadableStreams specifically give you methods for representing potentially infinite sources of data; where "processing" is done chunk-by-chunk.
WritableStreams are the dual to this concept - representing a sink that can consume potentially infinite chunks of data. Furthermore, there's an additional (undocumented on MDN) concept called a TransformStream; which is just the combination of the two - representing a chunk-by-chunk transform of data.
My question is pretty simple - why would Firefox abstain from implementing the WritableStream API, when Chrome and even IE edge support it? Is there a particular philosophical reason for not implementing it? Particularly, the ByteStream variants of streams (which haven't been fully fleshed out in the spec apparently) I find suspect.
No philosophical reason, just a pragmatic one I think. Unlike ReadableStream, which is used in the fetch response API, no standard Web API uses the WritableStream pattern yet (modulo its own
new WritableStream()constructor, which serves mostly as a tool for JS to read streams through piping right now).This matters in two respects. The first is prioritizing resources (patches welcome!)
The second is that implementing a browser API that uses the WritableStream pattern helps ensure a good implementation of that pattern, which is still relatively new. Byte streams in particular need to be performant.
Support for WritableStream in Firefox is being tracked here.
Some new WritableStream-based Web APIs are in the process of being standardized in the W3C, and will likely change the situation in Firefox. But they are still in the early stages. Two of them are:
Chrome and Edge have experimental implementations of WebTransport behind a pref, which is likely related to them having support for WritableStream early.