Why ArrayBuffer?

[bakkot]

I liked your blog post, but one thing caught my eye: fsx.arrayBuffer(filePath).

ArrayBuffer is almost never what you want because you can't read from one directly. You have to create a view like a Uint8Array to actually read it. And lots of methods don't accept an ArrayBuffer, only a Uint8Array or Buffer wrapper.

That seems counter to the ethos of "Common cases should be easy". The common case for reading bytes wants a Uint8Array, not an ArrayBuffer.

And of course if you do need an ArrayBuffer for some reason (though this is extremely rare) you can do bytes().buffer and get it.

[nzakas]

That's a fair assessment. I initially started out by copying methods from the Response object, assuming that's what people would be familiar with and want (along with text() and json()), but perhaps this one is worth revisiting.

[bakkot]

Yeah, I think that's kind of a legacy thing. At this point the web platform generally uses Uint8Array for byte buffers.

[bakkot]

(Incidentally if you were going to provide a method to vend a Uint8Array, I would just call it .bytes().)

[bakkot]

Yeah, looks like it is probably a legacy thing.

[nzakas]

The new bytes() method has been added and write() now access ArrayBuffer view as an argument.

[bakkot]

Nice, though checking the implementation for write, it looks like you're writing the entire backing .buffer to the output, instead of only the part actually viewed by the Uint8Array.

To give a concrete example:

let base = new Uint8Array([5, 6, 7, 8]);
let sub = base.subarray(1, 3);
await fsx.write("file", sub);

should only write the fours bytes 6 and 7 to "file", not all four bytes.

[nzakas]

Please open an issue.