First crack at a Streams proposal

Nuno Job nunojobpinto at
Mon Apr 15 14:29:49 PDT 2013

If fragmentation is bad why propose something that was never experimented
and diverged completely from what we learned with node?

Would love to understand the technical merits on why this is better than
node streams and why streams need to be in JS. I'm sure you have a
reasoning, i for once would like to know what it is. It's likely that
others do too.


ps. would appreciate keeping the discussion civilized and fallacy free (eg.
name dropping)

On Monday, April 15, 2013, Andrea Giammarchi wrote:

> of course, that is just my opinion.
> I am looking forward to read others ... meanwhile, in texas JS, a talk
> about node streams:
> Regards
> On Mon, Apr 15, 2013 at 2:12 PM, Andrea Giammarchi <
> andrea.giammarchi at <javascript:_e({}, 'cvml',
> 'andrea.giammarchi at');>> wrote:
>> I've implemented Alex Future proposal in JS before he did as prototype
>> and for tests.
>> However, Futures aren't used that much in node.js and spec'd like that
>> are nice.
>> However, I would not compare those two things.
>> If you propose Streams after Futures where Futures are less common in
>> node but Streams are one of the major things I think you should consider
>> more the current used node approach.
>> I don't see Future and Stream as different containers of the same thing
>> with identical functionality, sorry.
>> This is all I am saying.
>> Regards
>> On Mon, Apr 15, 2013 at 2:04 PM, Tab Atkins Jr. <jackalmage at<javascript:_e({}, 'cvml', 'jackalmage at');>
>> > wrote:
>>> On Mon, Apr 15, 2013 at 1:51 PM, Andrea Giammarchi
>>> <andrea.giammarchi at <javascript:_e({}, 'cvml',
>>> 'andrea.giammarchi at');>> wrote:
>>> > It's a nice effort but I agree with Nuno that fragmentation even on
>>> these
>>> > things already in production (despite the versioning) out there and
>>> already
>>> > working practically for the real-world isn't any good for the next
>>> future of
>>> > the JS community.
>>> Fragmentation of concept is exactly what standardization helps to
>>> solve - the role of standards is to, well, standardize, especially
>>> after the market has explored the problem space already.  Futures were
>>> long-overdue when Anne finally specced them, having been around in
>>> lots of languages including JS in many forms, and I think Streams are
>>> in a similar boat.
>>> > Also, JS has been kept general purpose enough, I would not try to
>>> influence
>>> > the language too much after DOM and W3C APIs and I thought this was
>>> also
>>> > same idea of TC39.
>>> I don't understand this sentence.  It *sounds* like you're trying to
>>> say that Streams aren't general-purpose enough for JS to standardize,
>>> and should be left to DOM/W3C to do.  Is this correct?
>>> If so, I disagree, and think that several other people on es-discuss
>>> do as well.  (For example, Alex, Yedua, and Dave have been responding
>>> to me about this proposal in Twitter.)  In general, a Stream is just
>>> another container type, and is as general as an Array or Set.  Plenty
>>> of *specific* instances or subclasses of Streams are appropriate for
>>> individual DOM/etc specs to define, but we need to agree on the
>>> general concept first, and es-discuss folks seem well-suited to help
>>> develop this.
>>> ~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list