… and gets discussion elsewhere too, such as this twitter thread with some implementers/standards folks weighing in.
Now that we have some precedent with TextDecoderStream/TextEncoderStream it’s worth collecting the set of such additional transcoding streams for which there has been demand, and look at whether there’s a generic API that could provide these, or if some require separate APIs but we can at least identify commonalities.
The transform stream API is better for web developers because it is an established pattern that is expected to work. It would be unfortunate if you used one pattern for text encoding and another for byte encrypting. It also makes it clear to web developers that such a transformation is stateful, whereas encrypt() would be holding the state implicitly through a closure.
The transform stream API is better for spec authors and implementers, because it automatically takes care of backpressure for you. Having to implement the proper queue-size-tracking there yourself is somewhat nightmareish.
A few use-cases I had in mind for gzip/brotli streaming compression:
Compression of uploaded payload - today analytics providers ship non-negligible code in order to compress the data they gather and upload to their servers. Native compression support in the browser would mean they can ship less code and (probably) compress their data faster.
Custom delta compression schemes - Having support for SW based compression streams with custom dictionaries can enable developers to role their own delta compression schemes, using previously cached versions of the content as dictionaries.