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

91–100 of 103 posts

Re: Goodbye, Node.js Buffer

#91

Post by silverwind »

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]'; } ```

> `Uint8Array.prototype.isPrototypeOf` and `instanceof Uint8Array` do not work across realms (frames, Node.js VM, etc).

That sounds like a bug in those implementations.

Re: Goodbye, Node.js Buffer

#92

Post by eyelidlessness »

silverwind wrote: post #91
mofle wrote: post #20

Earlier quoted context omitted.

`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]'; } ```

> `Uint8Array.prototype.isPrototypeOf` and `instanceof Uint8Array` do not work across realms (frames, Node.js VM, etc). That sounds like a bug in those implementations.

That’s a reasonable intuition, but it’s not a bug. Global scopes are isolated between realms by design, and that applies to built-ins as well as their prototype chains.

Re: Goodbye, Node.js Buffer

#93

Post by mhitza »

cxr wrote: post #81
SahAssar wrote: post #79

Earlier quoted context omitted.

How would you define it? The wiki article for it in the context of software ( https://en.wikipedia.org/wiki/Proprietary_software ) seems to pretty much stand it in opposition to open licenses, but I also have a sort of gut feeling that it could also refer to interfaces in OSS that are not designed to re-implementable. Not sure about that though.

"Nonstandard and controlled by one particular organization." https://en.wiktionary.org/wiki/proprietary > XBL, a precursor to Web Components in use in Firefox for 15+ years before any ordinary webdev was talking about shadow DOM, was open source in every sense, for example. It was also proprietary. See also: "Problems with XUL". > XUL is a proprietary technology developed by Mozilla and only used by Mozilla. https://…

I don't know when that page was written, but there were other developers that were using XUL before it was deprecated. The only one that comes in mind right now is ActiveState and their Komodo Edit/IDE. But there used to be more developers and I recall their being a dedicated page that listed those other products built on XUL.

The documentation of it, and the jump in complexity when it came to XPCOM (which were written in C++), were the reason (in my opinion) why platforms like Electron got popular instead of XUL.

Re: Goodbye, Node.js Buffer

#94

Post by moring »

wruza wrote: post #54

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 t…

> 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.

Re: Goodbye, Node.js Buffer

#95

Post by lemper »

wayvey wrote: post #3

It's good to see that people care about native JS standards. I'm a bit concerned how Bun seems to be adding their own proprietary APIs to their JS runtime, and can't help feeling that it could be intentional vendor lock-in. Since they are venture backed I'm sure they want some ROI from the project eventually and if they start charging money it will be harder to switch away due to the proprietary APIs without refactor…

> can't help feeling that it could be intentional vendor lock-in.

it's always vendor lock-in. can never trust companies, mate!

Re: Goodbye, Node.js Buffer

#96

Post by [deleted] »

mofle wrote: post #18
supermatt wrote: post #8

> Buffer also comes with additional caveats. For instance, Buffer#slice() creates a mutable segment linked to the original Buffer, while Uint8Array#slice() creates an immutable copy, resulting in possible unpredictable behavior. I can see how the Buffer behavior here would be preferable in cases where performance is important or memory constrained environments.

Uint8Array has this too, but it's called `.subarray()`. The problem is that Buffer is a subclass of Uint8Array, but changes the behavior of the `.slice()` method.

[deleted]

Re: Goodbye, Node.js Buffer

#98

Post by cxr »

mhitza wrote: post #93
cxr wrote: post #81

Earlier quoted context omitted.

"Nonstandard and controlled by one particular organization." https://en.wiktionary.org/wiki/proprietary > XBL, a precursor to Web Components in use in Firefox for 15+ years before any ordinary webdev was talking about shadow DOM, was open source in every sense, for example. It was also proprietary. See also: "Problems with XUL". > XUL is a proprietary technology developed by Mozilla and only used by Mozilla. https://…

I don't know when that page was written, but there were other developers that were using XUL before it was deprecated. The only one that comes in mind right now is ActiveState and their Komodo Edit/IDE. But there used to be more developers and I recall their being a dedicated page that listed those other products built on XUL. The documentation of it, and the jump in complexity when it came to XPCOM (which were writt…

Not relevant to this topic.

Re: Goodbye, Node.js Buffer

#99

Post by cxr »

Exoristos wrote: post #83
cxr wrote: post #82

Earlier quoted context omitted.

> (How did we get to a place where everything is this bad?) Not vetting the bedrock you chose to build upon; deciding to rely on the unreliable. ("Everything" is an overstatement.)

What's better?

Vetting it.

Re: Goodbye, Node.js Buffer

#100

Post by mhitza »

cxr wrote: post #98
mhitza wrote: post #93

Earlier quoted context omitted.

I don't know when that page was written, but there were other developers that were using XUL before it was deprecated. The only one that comes in mind right now is ActiveState and their Komodo Edit/IDE. But there used to be more developers and I recall their being a dedicated page that listed those other products built on XUL. The documentation of it, and the jump in complexity when it came to XPCOM (which were writt…

Not relevant to this topic.

I think it's relevant as the linked post states that Mozilla was the single user of the XUL runtime.
Post reply on HN