Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Node.js Buffer

sindresorhus.com

Post reply on HN
Print view View original

21–30 of 103 posts

Re: Goodbye, Node.js Buffer

#21

Post by mofle »

jongjong wrote: post #12

TBH I prefer Buffer as an abstraction. Too bad it didn't make it into native JS standard. I can't think of many use cases in JS land were Uint8Array, Uint16Array, Uint32Array, Int8Array would be absolutely necessary. Seems more useful for perf optimizations. For WebAssembly? Surely a plain array of numbers can be used in most cases. The main use case for Buffer IMO is to convert between different formats like Base64,…

> I can't think of many use cases in JS land were Uint8Array, Uint16Array, Uint32Array, Int8Array would be absolutely necessary.

Buffer is a subclass of Uint8Array.

Re: Goodbye, Node.js Buffer

#22

Post by [deleted] »

thomasreggi wrote: post #9

I've been using the native Uint8Array that Deno provides and it's been great overall. From time to time I may need to covert away from a Buffer type and it's a little bit of a headache, but I think the ecosystem is supporting Uint8Array, at least on the server very well.

[deleted]

Re: Goodbye, Node.js Buffer

#23

Post by tomjakubowski »

jongjong wrote: post #12

TBH I prefer Buffer as an abstraction. Too bad it didn't make it into native JS standard. I can't think of many use cases in JS land were Uint8Array, Uint16Array, Uint32Array, Int8Array would be absolutely necessary. Seems more useful for perf optimizations. For WebAssembly? Surely a plain array of numbers can be used in most cases. The main use case for Buffer IMO is to convert between different formats like Base64,…

Sized numerics are useful even in high level, loosely and dynamically typed languages. Two examples are binary (de)serialization and OpenGL. In Python, libraries for those generally use sized numerics.

High level languages will still want to do low level things

Re: Goodbye, Node.js Buffer

#24

Post by SuboptimalEng »

jongjong wrote: post #12

TBH I prefer Buffer as an abstraction. Too bad it didn't make it into native JS standard. I can't think of many use cases in JS land were Uint8Array, Uint16Array, Uint32Array, Int8Array would be absolutely necessary. Seems more useful for perf optimizations. For WebAssembly? Surely a plain array of numbers can be used in most cases. The main use case for Buffer IMO is to convert between different formats like Base64,…

Typed arrays are essential for web apps that use WebGL and WebGPU. Being able to send this type of data to run computations on the GPU can give you 1000x speed up.

You can see it in action on this WebGL fluid simulator[0] by PavelDoGreat.

[0] https://github.com/PavelDoGreat/WebGL-Fluid-Simulation

Re: Goodbye, Node.js Buffer

#25

Post by hersko »

TSiege wrote: post #7
hersko wrote: post #2

I recently ran into an issue where I needed to store an Uint8Array as a BYTEA in postgres. When i stored it directly, the Uint8Array would be modified and made bigger. When i converted it to a buffer and then stored it, it would work. Still not sure why that was the case.

I wonder if that's a lack of good support for Uint8Array in the client you're using with postgres?

Not sure. I was using Sequalize for the ORM, but don't know if it was a Sequalize or postgres issue.

Re: Goodbye, Node.js Buffer

#26

Post by Etheryte »

davidmurdoch wrote: post #5

Buffer's `slice` is nice to have in many cases though. The pool makes it generally faster. And `allocUnsafe` is a great feature! I like Buffer.

As discussed in another thread, `subarray()`[0] fills the same purpose.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Goodbye, Node.js Buffer

#28

Post by strken »

josephcsible wrote: post #15

> buffers expose private information through global variables, a potential security risk. Does JavaScript's security model let you effectively sandbox scripts running in the same context from each other? If not, then why does this matter?

From a cursory read, it matters because all Buffer.from(...) calls use a shared buffer, and buffer over-reads are a much more common vulnerability than easy access to arbitrary memory.

Not a security expert etc.

Re: Goodbye, Node.js Buffer

#29

Post by spicykraken »

mofle wrote: post #20
ravenstine wrote: post #11

I agree with using Uint8Array (although it's really ArrayBuffer that's the key difference), but what is up with the author using an NPM package to do something as trivial as checking if an object is a Uint8Array? `Uint8Array.prototype.isPrototypeOf` should be perfectly adequate and doesn't involve adding an attack vector to your application.

`Uint8Array.prototype.isPrototypeOf` and `instanceof Uint8Array` do not work across realms (frames, Node.js VM, etc). Feel free to copy-paste the function to your own code base if you don't want the dependency: ``` const objectToString = Object.prototype.toString; export function isUint8Array(value) { return value && objectToString.call(value) === '[object Uint8Array]'; } ```

What do you mean by "across realms"?

Is that just another way of saying `Uint8Array.prototype.isPrototypeOf` and `instanceof Uint8Array` are not available in all JS environments?

I guess what I'm asking is the definition of a "Javascript Realm" in case I'm thinking it's something different.

Re: Goodbye, Node.js Buffer

#30

Post by vendiddy »

I had to deal with binary data in a project recently and all the options made my head spin. File, Blob, Buffer, ArrayBuffer, Uint8Array, and so on.

Was very confused on what to use!

Post reply on HN