And if you want to work with text then you need to use the asymmetric TextEncoder/TextDecoder 🫠

And it is still less convenient if you want to read an ArrayBuffer in a heterogeneous way, given that you have to wrap it in a DataView and pay attention to byteOffset and byteLength, if you want to ensure you overlap with a corresponding TypedArray. But then you do get read/write of different ints

Eg paying attention to the byteOffset and alignment for larger element sizes than u8’s.

TypedArrays are also just catching up to the powerful abstraction that Buffers are with browser currently adoption hex/base64 encoding as methods rather than everyone rolling their own

As far as I remember, Buffer also did not foresee the need to separate between an allocation and a view like they did with TypedArrays, where ArrayBuffer is the allocation and Uint8Array (as an example) is a view. Which also means you have to be careful when using ArrayBuffers directly!

Adding to the conversation; Buffer historically came before there were any TypedArrays. However the choice of `.slice` for pointing to the same memory seems unfortunate today given that slicing a normal array also creates a copy, but I guess slice was more familiar than inventing a new method

Have kept on my phone for years. From DTN 2019. Believe that is you and Mikael on the left. Photo taken by heapwolf. Thinking of all the people Mikael inspired