2 ms·

So the only important difference is that Buffer creates a mutable view at slice(). It could use a better/distinct name for sure, e.g. mutableView(). But do you

by wruza 3y ago

So the only important difference is that Buffer creates a mutable view at slice(). It could use a better/distinct name for sure, e.g. mutableView(). But do you actually want to always copy a slice that is big enough? This ideological pedantic purism which eliminates practical use cases is in my book just that - impractical pedantic purism. It’s easy to advocate for when your job is shaping landscapes without having to walk these. And yes, I’m writing this still having flashbacks from ESM-only “transition”, which was more like throwing everyone into freezing waters with the promise it will warm up eventually.

rattlesnakedave 3y ago
> So the only important difference is that Buffer creates a mutable view at slice(). No, it also (from the article): > introduces numerous methods that are not available in other JavaScript environments. Consequently, code leveraging Buffer-specific methods needs polyfilling, preventing many valuable packages from being browser-compatible.
- wruza 3y ago
  The polyfill argument is good, but it addresses a world where you just push html, css and js files. We live in a different one. It is valid, but more on a wishful thinking side rather than practical. And when you avoid calling it “polyfill”, it simply turns into a useful compatibility/extension library. I find it strange to argue about one dependency but then importing few others, with the only difference in taxonomy.
moring 3y ago
> So the only important difference is that Buffer creates a mutable view at slice(). It could use a better/distinct name for sure, e.g. mutableView(). But do you actually want to always copy a slice that is big enough? I think you are missing the point. Mutable and copied slices both have their use, and maybe a method that sometimes copies and sometimes shares does too. The problem with Buffer is that it overrides a method with well-defined semantics, then violates those. Buffer is a subclass of UInt8Array, but not a subtype nor Liskov-substitutable. In practical terms, when you get a UInt8Array and even check that it in fact is a UInt8Array, you no longer know that .slice() does even though UInt8Array's documentation explains how every UInt8Array behaves, because that documentation is now wrong. If the UInt8Array you get is a Buffer, then it is both a buffer and a UInt8Array but its .slice() behaves differently than expected.

by wruza 3y ago

rattlesnakedave 3y ago

> So the only important difference is that Buffer creates a mutable view at slice(). No, it also (from the article): > introduces numerous methods that are not available in other JavaScript environments. Consequently, code leveraging Buffer-specific methods needs polyfilling, preventing many valuable packages from being browser-compatible.

wruza 3y ago
The polyfill argument is good, but it addresses a world where you just push html, css and js files. We live in a different one. It is valid, but more on a wishful thinking side rather than practical. And when you avoid calling it “polyfill”, it simply turns into a useful compatibility/extension library. I find it strange to argue about one dependency but then importing few others, with the only difference in taxonomy.

moring 3y ago

> So the only important difference is that Buffer creates a mutable view at slice(). It could use a better/distinct name for sure, e.g. mutableView(). But do you actually want to always copy a slice that is big enough? I think you are missing the point. Mutable and copied slices both have their use, and maybe a method that sometimes copies and sometimes shares does too. The problem with Buffer is that it overrides a method with well-defined semantics, then violates those. Buffer is a subclass of UInt8Array, but not a subtype nor Liskov-substitutable. In practical terms, when you get a UInt8Array and even check that it in fact is a UInt8Array, you no longer know that .slice() does even though UInt8Array's documentation explains how every UInt8Array behaves, because that documentation is now wrong. If the UInt8Array you get is a Buffer, then it is both a buffer and a UInt8Array but its .slice() behaves differently than expected.