First crack at a Streams proposal

Tab Atkins Jr. jackalmage at
Mon Apr 22 16:49:02 PDT 2013

On Mon, Apr 22, 2013 at 4:13 PM, Isaac Schlueter <i at> wrote:
> On Sat, Apr 20, 2013 at 12: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's not fully-general counter-argument, because it's not an argument.
>  It's a request for more information.  Until I have that information,
> I don't have enough information to form a reasonable opinion.

That request is nearly always followed with an (explicit or implied)
"And if it can be, why should we do it? Leave it to libraries!"
statement.  If you did not intend this, then I apologize.

> I read your proposal.  It appears to be something that is
> implementable with today's current JavaScript.  Am I mistaken?  If so,
> how so?  (Ie, what new language semantics or primitives are required?)

You need Object.observe to do reactive values as an event stream.  You
can do event streams (turning DOM Events into a stream) with today's

> If I'm not mistaken, then where's the reference implementation?  I
> don't even see example code.  I figured that I must be missing
> something.

Apologies for the mismatch in expectations.  I recognize that
reference implementations are more *customary* when proposing things
in JS that don't depend on new primitives.  Instead, I provided a spec
that sketched out appropriate details (and can be filled in further as
necessary).  For the purpose of discussion of the idea, the two should
be roughly equivalent.

> Search npm and github before making claims about what things would be
> damned by the request for a reference implementation in advance of a
> specification.

My comment was not in response to a request for a reference
implementation.  (This side-trek is irrelevant, though - no need to
respond to it.)

>> Please note that the proposal topping this thread is already
>> long-obsolete.
> Then please update the thread with the updated proposal,

To avoid any confusion in this thread, I started a second thread with
my updated proposal.  (Though the proposal in the OP of that thread is
*also* obsolete, I updated the thread when I majorly changed the
proposal.  My blog post, which always has the current state of the
proposal, is also in this thread and the other.

> and
> preferably a link to the github account with the reference
> implementation, if such a thing exists.
> If such a thing does not exist, please explain why it is not feasible
> to write an implementation of this with today's language semantics.
> If I seem a bit impatient, it is because I am eager to have an opinion
> about this idea of yours, but I find myself incapable of responsibly
> having an opinion without seeing it in action.
> As you say, the concept of event streams appears in many libraries.  I
> work daily with Node.js, which is full of event emitters and binary
> data streams.  You mentioned that it would be easy to implement binary
> streams on top of your streams idea.  I'd like to see that.  I know
> from firsthand experience that streams can be surprisingly hard to get
> right.  In my opinion, if you can't easily implement TCP, TLS, and
> Zlib on a stream implementation, then you haven't gotten it right.
> So, the fact that an implementation has not yet been shown seems quite
> strange to me, because that would be the *first* thing that I'd expect
> anyone would want to see, and it seems like it'd only take a few
> hundred lines of code to do.  I say that because other "streaming" FRP
> pattern libraries have been implemented in just a few hundred lines.
> Look at the work of Dominic Tarr (dominictarr) or Irakli Gozalishvili
> (gozala) on npm and github.
> Until there is an implementation, I don't really see what there is to
> talk about.  As I said, this is not a counter-argument, because as far
> as I'm concerned, there's nothing to even argue about!

Again, I'm aware that JS proposals often come with a reference
implementation, or at least a sketch of one.  That's not strictly
necessary to review and talk about a proposal, however.  If you think
that you are unable to even discuss the proposal without such a
reference implementation, then I'm sorry that we will have to lose
your voice until I have the time and engery to provide such.


More information about the es-discuss mailing list