TextDecoder looks fine, but I'm a bit wary of using TextEncoder naively. It requires allocating a Uint8Array for each string. Each Uint8Array comes with 200 bytes of overhead[0]. Depending on your algorithm you can end up with thousands if not millions of tiny strings. While even phones will probably have enough RAM to handle a few hundred megabytes these days, that will slow things down simply from an allocation/garbage collection perspective.
Furthermore, typed array allocation used to be incredibly slow compared to array allocation - the gap is smaller now but it is still slow enough to be a bottle-neck in my code.
The quote below is from a V8 dev replying to someone who opened an issue about this slow allocation. It is from 2012, but it still applies:
> The reason is simply that while constructing Array is done exclusively in the Javascript virtual machine and an allocation in the VM's heap, constructing a TypedArray involves the browser binding (at least in Chrome) and allocation outside the VM's heap. The former can be properly optimized, while the latter cannot. Future optimizations in this area are already on our radar, but have rather low priority.
> Generally speaking, typed arrays are good if you want to allocate a long-living dense array with a certain type and size. Array objects are better if you want to create temporary arrays often.
I hope things will improve now that Typed Arrays finally get some proper love thanks to WASM.
[0] https://stackoverflow.com/questions/45803829/memory-overhead...
In V8. I believe the overhead is a lot lower in SpiderMonkey. I can't speak for other implementations.
https://caniuse.com/#feat=textencoder