News for hackers. Stuff that matters.
Re:We deserve a better streams API for JavaScript by ai-christianson on Friday February 27, 2026 @09:57AM (#47181232)
The point about BYOB reads is spot on. It's frustrating that such a critical feature for performance and reducing GC pressure ended up being so difficult to implement correctly in the WHATWG standard. A simpler, more ergonomic approach to buffer management would go a long way for those of us building high-performance data processing tools in JS.
Re:We deserve a better streams API for JavaScript by slowcache on Friday February 27, 2026 @10:18AM (#47181523)
> high-performance data processing tools in JS

I may be naive in asking this, but what leads someone to building high perf data tools in JS? JS doesn't seem to me like it would be the tool of choice for such things

Re:We deserve a better streams API for JavaScript by afavour on Friday February 27, 2026 @12:04PM (#47182857)
Browsers are now able to stream files from disk so you can create a high performance tool that'll read locally, do [x] with it and present the results, all without any network overhead.
Re:We deserve a better streams API for JavaScript by n_e on Friday February 27, 2026 @10:35AM (#47181733)
I have a SaaS project where the backend is in JS. I also have some data processing to do with large file (several TB). Doing it is in JS is more convenient as I can reuse code from the backend, and it is also the language I know best.

Performance-wise, I get about half the throughput I had with the same processsing done it rust, which doesn't change anything for my use-case.

However that's not really relevant to the context of the post as I'm using node.js streams which are both saner and fast. I'm guessing that the post is relevant to people using server-side runtimes that only implement web streams.

Re:We deserve a better streams API for JavaScript by moron4hire on Friday February 27, 2026 @10:47AM (#47181884)
You don't always have a choice on where you deliver your software. It'd be nice to have good tools wherever you are forced to work.
Re:We deserve a better streams API for JavaScript by thadt on Friday February 27, 2026 @10:32AM (#47181709)
Browsers
Re:We deserve a better streams API for JavaScript by speed_spread on Friday February 27, 2026 @10:43AM (#47181830)
Since when are browsers themselves built in JavaScript? Mainstream, fast ones?
Re:We deserve a better streams API for JavaScript by thadt on Friday February 27, 2026 @11:18AM (#47182297)
Clarification - in the past when I've written high performance data tools in JS, it was almost entirely to support the use case of needing it to run in a browser. Otherwise, there are indeed more suitable environments available.

To your question, I was about to point out Firefox[1], but realized you clarified 'mainstream'[2]...

[1] https://briangrinstead.com/blog/firefox-webcomponents

[2] https://gs.statcounter.com/browser-market-share

Re:We deserve a better streams API for JavaScript by jitl on Friday February 27, 2026 @11:13AM (#47182220)
but instead of trying to solve that, this api is just like “too hard no one uses it let’s forget about it”.

right now when i need to wrangle bytes, i switch languages to Golang. it’s easy gc language, and all its IO is built around BYOB api:

interface Reader { read(b: Uint8Array): [number, Error?] }

you pass in your own Uint8Array allocation (in go terms, []byte), the reader fills at most the entire thing, and returns (bytes filled, error). it’s a fully pull stream API with one method at its core. now, the api gets to be that simple because it’s always sync, and blocks until the reader can fill data into the buffer or returns an error indicating no data available right now.

go has a TeeReader with no buffering - it too just blocks until it can write to the forked stream.

https://pkg.go.dev/io#TeeReader

we can’t do the same api in JS, because go gets to insert `await` wherever it wants with its coroutine/goroutine runtime. but we can dream of such simplicity combined with zero allocation performance.