You can have the global function and make it work on "chunked partial inputs" while maintaining the state between calls (that state can be hidden in a closure or made explicit as an argument or a receiver - functions in JS can be called on objects even if they were defined outside of them). The very bad example of this is C's `strtok`, but it's pretty typical for JS to encapsulate the state in a closure to get similar functionality.

Said another way: the functional, simplified interface doesn't mean you have to get simplified or lacking functionality. Haskell wouldn't exist if that was the case. The simplified interface providing as much functionality as the more complex interface is possible because the expressive power of JS is leagues above Java - porting Java patterns that emerged due to Java's shortcomings (some call them "design decisions", and they're also right) to JavaScript is simply not a good use of JS as a language.

This is what GP is talking about. Chunking can be done cleanly with very few internal functions (and without changing the call signature, if you want), but you're implying it must be a class and already thinking about hypothetical hacks

> I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial inputs

Fight me.

Javascript has a separate TextDecoderStream class if you want to support chunked, partial inputs. The TextDecoder class doesn't support streaming input at all. And it never will, thanks to the existence of TextDecoderStream.

TextDecoder only provides 1 method - TextDecoder.decode(). And the method is pure! So you could just make it a global method without any loss of functionality. The entire class has no mutable state whatsoever. Its just a container for some options, passed into the constructor. Those options could just have been passed straight to a global decode() method.

https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder

This might be idiomatic C++, but its terrible javascript. I had a friend who worked on the Chrome team years ago. He said a lot of the browser engineers who design javascript APIs are C++ programmers who don't know javascript properly. So of course they port C++ ideas into javascript directly. They don't know any better. This is why javascript's standard library is an incoherent mess.

It wouldn't need to be a global, it could be mounted on String for example... And one doesn't necessarily prevent the other.

    String.fromUint8Array: (input: Uint8Array, encoding: string): String;

Would be a fine, simple addition where it probably should be. Maybe calling the default for UInt8Array "String.fromBinary" instead.