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

51–60 of 103 posts

Re: Goodbye, Node.js Buffer

#51

Post by mofle »

loudgas wrote: post #48
mofle wrote: post #41

Earlier quoted context omitted.

Completely different behavior is not an implementation detail. Changing method behavior in subclasses is part of inheritance, but it shouldn't confuse or mislead. In the case of Buffer and Uint8Array, the altered `.slice()` functionality isn't a mere implementation detail; it's a significant deviation. This inconsistency can lead to unexpected bugs, especially for those who assume similar behavior based on the inheri…

Any behavior that is not defined in the spec[0] is, by definition, an implementation detail. Relying on undefined behavior is a recipe for bugs. If you need an immutable array, and the spec doesn't require the returned array to be immutable, you should create one yourself. [0] https://tc39.es/ecma262/multipage/indexed-collections.html#s...

You are reading the wrong spec. That is `Array#slice`, not `TypedArray#slice`.

Correct spec: https://tc39.es/ecma262/multipage/indexed-collections.html#s...

Steps 14.g.i to 14.g.ix detail the transfer of data from the original TypedArray (O) to the new TypedArray (A). It involves reading values from the original and writing them to the new array's buffer, effectively duplicating the data segment. The process ensures both arrays are distinct with separate memory spaces.

Re: Goodbye, Node.js Buffer

#52

Post by pictur »

I guess this is our new nonsense after the ESM nonsense. Come on man start fucking all the npm packages as soon as possible. Don't forget to throw away backward compatibility.

Re: Goodbye, Node.js Buffer

#53

Post by ninepoints »

SuboptimalEng wrote: post #24
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

This isn't an argument against buffer though. Raw memory is raw memory

Re: Goodbye, Node.js Buffer

#54

Post by wruza »

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.

Re: Goodbye, Node.js Buffer

#55

Post by rattlesnakedave »

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

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.

Re: Goodbye, Node.js Buffer

#56

Post by bakkoting »

The proposal for native base64 support for Uint8Arrays is mine. I'm glad to see people are interested in using it. (So am I!)

For a status update, for the last year or two the main blocker has been a conflict between a desire to have streaming support and a desire to keep the API small and simple. That's now resolved [1] by dropping streaming support, assuming I can demonstrate a reasonably efficient streaming implementation on top of the one-shot implementation, which won't be hard unless "reasonably efficient" means "with zero copies", in which case we'll need to keep arguing about it.

I've also been working on documenting [2] the differences between various base64 implementations in other languages and in JS libraries to ensure we have a decent picture of the landscape when designing this.

With luck, I hope to advance the proposal to stage 3 ("ready for implementations") within the next two meetings of TC39 - so either next month or January. Realistically it will probably take a little longer than that, and of course implementations take a while. But it's moving along.

[1] https://github.com/tc39/proposal-arraybuffer-base64/issues/1...

[2] https://gist.github.com/bakkot/16cae276209da91b652c2cb3f612a...

Re: Goodbye, Node.js Buffer

#57

Post by bakkoting »

mofle wrote: post #38
vendiddy wrote: post #30

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!

- Blob: Immutable raw data container with a size and MIME type, not directly readable. - File: Like a Blob, but with additional file-specific properties (e.g., filename). - ArrayBuffer: Fixed-length raw binary data in JavaScript, not directly accessible. - Uint8Array: Interface for reading/writing binary data in ArrayBuffer, showing them as 8-bit unsigned integers. - Buffer: Readable/writable raw binary data containe…

Nit: "fixed-length" is no longer true as of very recently [1].

[1] https://github.com/tc39/proposal-resizablearraybuffer

Re: Goodbye, Node.js Buffer

#58

Post by eyelidlessness »

brundolf wrote: post #47
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…

The accusation of malice goes a bit far, but I agree it's a problem whether it's intentional or not. Bun takes a slapdash approach to shipping features and APIs, which means things get out fast but also rubs me the wrong way re: long-term implications and vision

I’ll vouch for non-malice. Bun’s creator frequently tweets about hypothetical APIs he may want to introduce, often seeking feedback explicitly. The ideas are always earnest “would you find this helpful?” sorts of things. (For what it’s worth, I frequently reply that these hypotheticals are a bad idea when they break expectations etc, at least if I can fit my reasoning in tweet length. I think this has been at least marginally successful in pushing back in some cases.)

The problem, with Bun but really with the ecosystem at large, is that shipping stuff is (still) the de facto way that standards kind of congeal into something resembling actual standards.

Re: Goodbye, Node.js Buffer

#59

Post by brundolf »

eyelidlessness wrote: post #58
brundolf wrote: post #47

Earlier quoted context omitted.

The accusation of malice goes a bit far, but I agree it's a problem whether it's intentional or not. Bun takes a slapdash approach to shipping features and APIs, which means things get out fast but also rubs me the wrong way re: long-term implications and vision

I’ll vouch for non-malice. Bun’s creator frequently tweets about hypothetical APIs he may want to introduce, often seeking feedback explicitly. The ideas are always earnest “would you find this helpful?” sorts of things. (For what it’s worth, I frequently reply that these hypotheticals are a bad idea when they break expectations etc, at least if I can fit my reasoning in tweet length. I think this has been at least m…

Yeah. I follow him on twitter too, and it's both impressive and distressingly chaotic the way he spitballs and then settles on APIs in the form of twitter surveys

Re: Goodbye, Node.js Buffer

#60

Post by ravenstine »

mofle wrote: post #46
ravenstine wrote: post #43

Earlier quoted context omitted.

I understand what you're saying, but that's actually in support of my point. This is still extremely trivial code to implement and, from what I can tell, doesn't warrant downloading an NPM package. Have we already forgotten the left-pad fiasco? This isn't meant as a personal attack on anyone, but we really need to frown upon needless dependencies, especially given the growing number of malicious NPM packages.

No one is forcing you to use it. You can choose to reimplement the code yourself or you can choose to copy-paste the code. I made the package for my own convenience as I need to transition a lot of packages from `Buffer` and I don't want to maintain duplicates of the code in every package. Others are free to use the package or not.

Hey, that's totally fine if that's what you want to do, especially if it's for your own convenience. What I'm trying to communicate really has nothing to do with whether anyone is being forced to install anything. My point is that there easily avoidable problems that are inherent to pulling in packages hosted elsewhere, and that programmers should consider whether they should avoid suggesting that using a third-party package for something that can be written by hand in a few minutes. That's all I'm saying. For your own use, this makes a lot of sense. If it were me, I would avoid sharing it, and I hope more programmers move away from relying heavily on other people's packages for tiny units of functionality. But I probably wouldn't have been vocal about that here if I knew your intent with that package (or that you even wrote it, which perhaps I missed somewhere).
Post reply on HN