Regardless, it’s a strictly worse api in the general case. And it’s on par with passing around an options object in the case you want to share the same options in multiple places.

If the current api is either the same or worse compared to a pure function version in all cases, I’d prefer the pure function version thanks.

> If the current api is [...] the same [...] compared to a pure function version in all cases, I’d prefer the pure function version thanks.

Why?

No, it would be an explicit dependency.

    // definition:
    function decodeText(input, [format | options])

    // use:
    decodeText(someBuffer, 'utf8')

    // or:
    const opts = {encoding: 'utf8', fatal: true, ignoreBOM: false}
    decodeText(someBuffer, opts)
    decodeText(somethingElse, opts)

Because a pure function is idiomatic, concise and clear. Its easier to use, easier to document and easier to understand. The only benefit of a class is that it encapsulates its state behind an interface. That makes sense for a BTree or a database. But TextDecoder has no mutable state. It has no state at all except for its passed-in configuration.

Decoding text is a verb not a noun. In programming, verbs are translated to functions, not classes. You don't have an "adder object" to add things. You don't have to instantiate a JSON stringifier before calling JSON.stringify. If thats not obvious, you may have spent too long in OO languages.