First crack at a Streams proposal

Tab Atkins Jr. jackalmage at
Mon Apr 15 16:01:08 PDT 2013

On Mon, Apr 15, 2013 at 3:40 PM, Domenic Denicola
<domenic at> wrote:
> From: Tab Atkins Jr. [mailto:jackalmage at]
>> I do somewhat resent the implication that I invented something wholly new without drawing on any existing APIs.  I looked at the syntaxes of several similar APIs in other languages while designing this, and took lessons from them.
> In that case I certainly apologize for my ignorance; I guess I'd never seen those existing APIs and thus, foolishly, assumed they were just your invention. Sorry about that.
> It would probably be helpful to all involved to get pointers to these APIs, since for a task like this we'll need as much inspiration as possible. Currently Dart's streams and Node.js streams are what we are mostly looking at, so more sources are definitely welcome, especially if they have novel ideas like this but proven in the field of other languages.

For example, examples and linked articles in
<>, and several articles
discussing LINQ and IObservable in C#, and various flavors of Task in
C# and other languages.  (I happen to think C# did a pretty good job
here.  I'd like to look into the Haskell APIs for this kind of thing,
but haven't done so so far.)

Dart's broadcast streams are extremely similar to my proposal, with
just some naming differences.  My crack at the API is designed for the
DOM applications I have in mind, so I didn't consider single-listener
cases, but that's probably easy enough to integrate (if you know
you're a single-listener stream, you probably want to buffer updates
until someone actually starts listening).

Node's streams are something quite different, though conceptually
related - they're heavily specialized to binary IO.  My proposal is
designed more to handle reactive programming-style things, or
first-class event streams from the DOM.  (DOM Events are great for the
tree-based abilities when you *have* a tree, but we currently use them
for a lot of non-tree things, where a more specialized event stream
API would be better and more powerful.  IO streams *might* be
integratable into this proposal, but I think we'll more likely end up
with something that has a similar-shaped API but is a fundamentally
separate thing.


More information about the es-discuss mailing list