HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
whatwg
streams
HTML2013–2026
whatwg / streams

streams

Streams Standard

Web Development
Explore on GitHubRead Hacker News discussions
9Distinct people
9Mentions
0Explicit recommenders
1.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Streams Standard

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year9 dated mentions

Observed mentions: 2013-11-04 10:16:55 UTC to 2026-02-28 07:31:26 UTC.

0122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC211
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC202
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

9 sources
yonran·Feb 28, 2026
I don’t know how ReadableStream.tee() got specified to backpressure when the faster branch is not consumed, since this is the opposite of what nodejs does when multiple Writables attached via Readable.pipe() and also the opposite of what the requirements document (https://github.com/whatwg/streams/blob/e9355ce79925947e8eb49...) says: “letting the speed of the slowest output determine the speed of the tee”. I like the idea of the more ergonomic, faster api in new-stream with no buffering except at Stream.push(). NodeJS and web streams put infinitely expandable queues at every ReadableStream and WritableStream so that you can synchronously res.write(chunk) as much as you want with abandon. This API basically forces you to use generators that yield instead of synchronously writing chunks.
In A better streams API is possible for JavaScript
dgroshev·Sep 26, 2024
Every single JS future is boxed. Moreover, they aren't just boxed, they are often backed by a hashmap (which may or may not be optimised away by the JIT). Elaborate allocation-free async is not an apple-to-apples comparison. JS does support concurrent execution, Promise.all is an example. Without it, JS async would make little sense. The problem very much exists there, and try-catch is only a surface-level answer. As you can see here [1], the interaction of cancellation and async in JS is at least just as (or more) complex than in Rust. By the way, multithreading has little to do with Pin. I presume you're thinking of Send bounds. "To work at all" is very dismissive. Those wrappers are complex, but very well abstracted, well defined, and robust, the complexity is essential. Again, look at [1], JS async is hardly less complex, but also muc
Read the rest
h more vague and ill-defined. [1]: https://github.com/whatwg/streams/issues/1255
In Rewriting Rust
bakkoting·Oct 25, 2023
Yeah, in your case I think most of the complexity is actually on the ReadableStream side, not the base64 side. The thing that I'd actually want for your case is either a TransformStream for byte stream <-> base64 stream (which I expect will come eventually, once the simple case gets done; it's also easy in userland [1]), or something which would let you read the entire stream into a single Uint8Array or ArrayBuffer, which is a long-standing suggestion [2]. --- > Why does de-chunking a byte array need to be complicated Keep in mind the concat proposal is _very_ early. If you think it would be useful to be able to concat Uint8Arrays and have that implicitly concatenate the underlying buffers, [3] is the place to open an issue. --- > You have made me realize I don't even know what the right venue is to vote on stuff. How should I signal to T
Read the rest
C39 that e.g. Array.fromAsync is a good idea? Unfortunately, it's different places for different things. Streams are not TC39 at all; the right place for suggestions there is in the WHATWG streams repo [4]. Usually there's already an existing issue and you can add your use case as a comment in the relevant issue. TC39 proposals all have their own Github repositories, and you can open a new issue with your use case. Concrete use cases are much more helpful than just "this is a good idea". Though `fromAsync` in particular everyone agrees is good, and it mostly just needs implementations, which are ongoing; see e.g. [5]. If you _really_ want to advance a stage 3 proposal, you can contribute a PR to Chrome or Firefox with an implementation - but for nontrivial proposals that's usually hard. For TC39 in particular, use cases are only really valuable pre-stage-3 proposals. [1] https://github.com/lucacasonato/base64_streams/blob/7c4ed815... [2] https://github.com/whatwg/streams/issues/1019 [3] https://github.com/jasnell/proposal-zero-copy-arraybuffer-li... [4] https://github.com/whatwg/streams [5] https://bugs.chromium.org/p/v8/issues/detail?id=13321
In Goodbye, Node.js Buffer
domenicd·Apr 2, 2017
Hey there, I'm both the author of the browser streams spec [1] and the current champion of the async iteration spec [2] that this article discusses. We have, in fact, thought through the interaction here :). johnsonjo got things basically right in his response. We go into more detail in the streams FAQ, including the connection to observables: - "How do readable streams relate to observables or EventTarget?" [3] - "How do readable streams relate to async iterables?" [4] The basic punchlines are: > Observables and readable streams both share the semantic of "zero or more chunks, followed by either an error or done signal". But beyond that, they are not very comparable. and > The best analogy is something like "readable streams is to async iterable as array is to sync iterable." That is, just like arrays are a specialized type of iterable o
Read the rest
ptimized for memory locality and random access, readable streams are a specialized type of async iterable optimized for things like off-main-thread data transfer and precise backpressure signaling. I do indeed expect us to start speccing the [Symbol.asyncIterator]() for readable streams, and shipping it (behind a flag at first) in Chrome, within the next month or so. [1]: http://streams.spec.whatwg.org/ [2]: https://tc39.github.io/proposal-async-iteration/ [3]: https://github.com/whatwg/streams/blob/master/FAQ.md#how-do-... [4]: https://github.com/whatwg/streams/blob/master/FAQ.md#how-do-...
In Async JavaScript Generators
spion·Apr 14, 2015
We have an inhouse solution which is basically a set of external functions that work with built in streams in a way that avoids frustration. Some of them can be found in https://github.com/spion/promise-streams - the others we haven't extracted to an npm module yet. (Promise streams also has a minimal extension of built in streams to make them work better with promises). We never managed to find a full replacement though. Probably not worth the effort either given that it will always have to wrap existing streams, and the only drawback of external functions is that you cannot invoke them as methods. Although, one contender that I have hopes for is WHATWG streams [1]. note: to replace event emitters we built https://github.com/doxout/promise-observer which gives you a lot more power and control in terms of execution order and goes away wit
Read the rest
h the "multiple events per object" stringy design that makes things harder for typesystems like typescript/flow. [1]: https://github.com/whatwg/streams
In Gotchas from Two Years with Node
spankalee·Apr 16, 2014
One thing missing from this picture is Streams - the multivalued analog to Promises (Futures in Dart). The button click example would be quite easy to handle, even without Zones, if the button had an onClick event stream, rather than taking a callback. This code, which doesn't work as intended: function thirdPartyFunction() { function fakeXHR() { throw new Error("Invalid dependencies"); } setTimeout(fakeXHR, 100); } function main() { button.on("click", function onClick() { thirdPartyFunction(); }); } main(); would instead look like this with a Streams-based API (I'm assuming a Dart-like API, since I don't know the proposed Stream API for JS): function thirdPartyFunction() { function fakeXHR() { throw new Error("Invalid dependencies"); } setTimeout(fakeXHR, 1
Read the rest
00); } function main() { button.on("click") .listen(function onClick() { thirdPartyFunction(); }) .onError(function onError() { console.log("now it works with errors"); }) } main(); Since onClick is executed by the Stream, even a synchronous exception in thirdPartyFunction will be caught and given to the onError callback. JavaScript could really use a better DOM API with Promises and Streams in place of most callbacks. I think most of the Streams work is here: https://github.com/whatwg/streams So Zones aren't really needed here. They are very useful though. AngularDart uses them to intercept any external trigger of the event loop so that it can run it's change detection code (this is why they ported Zones to JavaScript). Dart's unittest library runs each test in a Zone to wait for outstanding microtasks and catch async errors that might happen after a test appears to have completed and associate it with the correct test. And of course using Zones to string together async stack traces or debugging is invaluable.
In Comparing Node.js Promises, Try/Catch, Angular Zone.js and Zone

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.