Edit: accuracy
Repo: https://github.com/isiahmeadows/proposal-es-streams
I've been observing (get it?) the two streaming proposals, and I feel they both fall short in ways that severely limit their applicability.
- https://github.com/tc39/proposal-observable boxes itself into a hole by making extensibility and composition really awkward.
- https://github.com/tc39/proposal-emitter thinks it's more general, but it also writes itself into a hole with all the conceptual complexity. (It's not actually simpler.)
I also struggled to see past the similarities between iterators and observable subscriptions, and so I ended up hitting the drawing board. And what I realized after doing some thinking (detailed pretty well in the repo) was that not only were iterators and observable subscriptions equivalent, but you can even model the greater observable itself using the same general abstraction but with the data transfer arrow pointing in the opposite direction. And as soon as I did that, the rest of the proposal practically wrote itself.
My proposal does come with a few added benefits:
- The cross-talk for backpressure can just be handled via return values. Literally no need to do anything.
- HTTP requests can take the form of an async stream, in which it returns a promise to the emit's result.
- Streams can be created without even creating a whole new global, and so polyfilling it would be very easy and lightweight.
- As it's protocol-based, polyfilling it for existing built-ins would be easy and straightforward.
- Syntax naturally comes out of the model, with little real need to think much on it.