First crack at a Streams proposal

Tab Atkins Jr. jackalmage at
Sat Apr 20 17:10:19 PDT 2013

On Sat, Apr 20, 2013 at 4:13 PM, Sean Silva <silvas at> wrote:
> On Sat, Apr 20, 2013 at 3:47 PM, Tab Atkins Jr. <jackalmage at>
> wrote:
>> On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter <i at> wrote:
>> > I'm not seeing what in this proposal can't be implemented in
>> > JavaScript as it is today.  Is there an implementation of this
>> > somewhere?  Are there any programs that use these streams?
>> This is a fully-general counter-argument against literally everything
>> that doesn't require new primitives, and so is useless as an actual
>> argument.  It would damn Promises/Futures, Sets, Maps, and a number of
>> other new things.
> I'm pretty sure there is no way to implement Maps with arbitrary keys in
> current JS.

It's possible, but lookup time is linear.  You need some variety of
language support to get constant-time lookups.

> As for Promises/Futures, I think that the argument is equally forceful
> against them as it is to the proposals in this thread.
>>  The valid version of this argument is about
>> *usefulness*, and there being unable to implement in current JS is a
>> supporting reason to add something, but not the only reason.
> My understanding from you wording is that you want this to be standardized
> into ECMAScript. That means that this change would be shipped in billions of
> devices and require implementation and testing effort across the globe and
> across every vendor. Are you sure it's utility would not be diminished if
> you just put a nice working implementation on github and register it with
> the various package managers that make installing and using such code dead
> simple? That would be a huge win since people would be able to start using
> it immediately.
> Concretely, compared to putting it on github and registering with package
> managers, what percentage usefulness increase do you expect to see by having
> this standardized?
> I think you're completely right, "The valid version of this argument is
> about *usefulness*", except it's about usefulness of standardizing it
> compared to other ways of making the code available, and not about the
> intrinsic usefulness of the API (which, I'll point out, does not appear to
> be convincingly established).

Whether TC39 ends up taking over standardization of promises/futures
or not, they're in the DOM and will be used by new standards.

I write standards for a living, so I'm well aware of the cost of
adding features.  I believe that addressing the use-cases of
functional reactive programming *is* important enough to justify
adding some new concepts to help them out, because it's an
intrinsically useful and high-value abstraction for a lot of
interactions with the DOM and with the user.  Event streams are an
early attempt by me to put something together for this, and I was
using es-discuss as a sounding board and design help for it.

Now that I've got a handle on what I think a good design is, my plan
is to retreat and spend some time studying and documenting existing
stream patterns in libraries, to try and discover what I might be
missing, or what areas I'm over/under-addressing.  When I'm done, I'll
report back with my findings.


More information about the es-discuss mailing list