DOM EventStreams (take two on Streams): Request for feedback

Tab Atkins Jr. jackalmage at gmail.com
Fri Apr 19 18:53:06 PDT 2013


On Thu, Apr 18, 2013 at 7:20 PM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> Makes sense, and thanks for clarifying!
>
> I guess my only hesitation is that promises evolved over many years, with the design we see in Promises/A+ today and its many implementations, including DOM Futures, being the result of convergent evolution in library-space. While your sugar is nice, I'd be hesitant to bless it as the one true async-loops sugar without at least some library-space evolution.
>
> In other words, why not try releasing your event streams as a library, and see what kind of adoption they get? If libraries as diverse as jQuery, WinJS, Ember, Angular, Dojo, and YUI end up all having some form of event stream in roughly that format, you know you're on to a winner :).

Yes, I'm going to start collecting event stream-like usages among
existing libraries now, and documenting what all they do.  This thread
has already been quite useful. ^_^

> It's a different scenario from promises, since they're part of the API contract that needs to be exposed when designing web APIs. It sounds like the fundamental API contract for your case is just a changing property, and the method of consuming that changing property could be done with sugar from any library. (Indeed, this is somewhat like how the fundamental API contract for async DOM APIs is now to return a relatively feature-less DOMFuture, which consumers can use alongside any full-featured promise library in order to get the sugar they desire.)

Hmm, good point.  The other major use of event streams - capturing DOM
Events - is also doable purely with sugar for now.

> Finally, on the issue of async loops, I'd argue that it's a tentative analogy. It's at least not nearly as clear how you could do a syntactic transformation like you can with promises, e.g. by introducing coroutines (cf. `await`). In fact, async loops to me seem like they'd be expressed as
>
> ```js
> while (await asyncCondition()) {
>     await asyncAction();
> }
> ```
>
> or, of course, its ES6 counterpart with `yield` and task.js-style wrappers.

"await" floats all async boats, so it's a fully general
counter-argument to async-helper concepts.  ^_^

The more direct analogy for event streams is generators and the
consumption/manipulation APIs you can run over them.  They capture the
notion of "loops" in a more general, functional way, and event streams
are just a push-based generator (that is, a generator with an async
data source).

~TJ


More information about the es-discuss mailing list