Re: [whatwg/encoding] Add Streams support (#72)

I'd like to clarify my understanding of the options, and my priorities when evaluating them.

I expect 99% of uses of the API will construct the object and pass it to `pipeThrough()` directly, so that's how I will describe the options:

1. `body.pipeThrough(new TextDecoder())`
2. `body.pipeThrough(TextDecoder.stream())`
3. `body.pipeThrough(new TextDecoderTransformStream())`

My number one priority is the ergonomics of this 99% usage pattern. In my opinion, option 1. is the clear winner here, requiring no extra effort for someone who already knows about TextDecoder. Option 3. is my second preference, because it is recognisable as constructing an object.

My second priority is to avoid traps for the 1% who are not using the above pattern. Specifically, I want to avoid people writing code that appears to work but mysteriously fails on some edge cases. Options 2. and 3. are ahead here, but I think the "distinct state" approach to 1. avoids all surprises and so is almost as good.

My third priority is to avoid users paying more in CPU and RAM for the feature than they have to. If `TextDecoder.stream()` returned a plain TransformStream it would be the cheapest option, but since we have decided the loss of `.encoding` and the other getters would be unacceptable, it instead needs to return a different type. This makes it cost roughly the same as option 3., and leaves option 1. as the most frugal.

My fourth priority is clarity of the standard text. Here I think 3. probably wins, but at a high price in verbosity.

My fifth priority is difficulty of implementation. Currently in Chrome option 3. is the easiest to implement, but that will change as the implementation evolves.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/72#issuecomment-376120032