I think a large part of the confusion here is that when Tab says "streams" he really means "observables" or "signals." As you point out, this would be completely inappropriate as a stream API, as it does indeed ignore many of the lessons Node learned. Surprisingly, it doesn't seem to draw on any of the existing observable or signal APIs that I've seen either, instead being some entirely new hybrid of promises and the nascent monads-in-JS movement. ________________________________ From: Nuno Job<mailto:nunojobpi...@gmail.com> Sent: 4/15/2013 15:43 To: Tab Atkins Jr.<mailto:jackalm...@gmail.com> Cc: es-discuss<mailto:es-discuss@mozilla.org> Subject: Re: First crack at a Streams proposal
Node.js has multiple iterations on Streams, and those were made in the hope to make them better. It's hard and has been an ongoing effort to make it perfect. That said it's quite surprising to see smart folks come to such different conclusions. Perhaps it's the lack of real life implementations and how these things affect real life programs and companies that use javascript. Almost all these concepts would have no chance to make it to node core. And some of these concepts are fairly advanced, when in node it took years to get get the basics right (the rest was left to npm and developers) Nuno
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
