The Web streams API has become ubiquitous in JavaScript runtimes but was designed for a different era. Here's what a modern streaming API could (should?) look like.

Cloudflare's platform is a leading provider of internet security and performance solutions, offering insights into web security, content delivery, and DNS management. Through documentation, blog posts, and webinars, Cloudflare provides insights into protecting websites and applications from cyber threats and improving performance. Developers and IT professionals can learn about CDN (Content Delivery Network), DDoS mitigation, and firewall configurations to secure and accelerate web traffic.

Cloudflare

A deep technical critique of the WHATWG Web Streams API by a Cloudflare/Node.js core contributor, arguing that its fundamental design choices — reader/writer locking, BYOB complexity, advisory backpressure, promise-heavy internals, and push-oriented TransformStreams — create serious usability and performance problems that cannot be fixed incrementally. The post presents a proof-of-concept alternative API built around async iterables as the core primitive, pull-based lazy evaluation, explicit backpressure policies, batched chunk delivery (Uint8Array[]), and synchronous fast paths. Benchmarks show the alternative running 3x–120x faster than Web streams across Node.js, Deno, Bun, Cloudflare Workers, and Chrome, with gains attributed entirely to design choices rather than implementation optimizations. The author frames this as a starting point for community discussion about what a modern streaming standard could look like.

We deserve a better streams API for JavaScript

<p>I agree. Stream APIs are so unintuitive that it’s hard to know if we’re doing the right thing and if nothing is leaking.</p>


<p>I barely understood the post content, i think i have to look into this more</p>
