dead-claudia / proposal-es-streams

Streams for JS
14 stars 0 forks source link

Unclear relation to *Observable* proposal #2

Open bergus opened 3 years ago

bergus commented 3 years ago

Quickly skimming the readme, your streams proposal seems to target the same use cases as observables - surely you're aware since you were active there as well. Can you please clarify how you expect the two to interact? Is the streams proposal supposed to supersede the observables proposal?

dead-claudia commented 3 years ago

Is the streams proposal supposed to supersede the observables proposal?

Yes. The idea is to replace observables entirely with a simpler, more flexible abstraction that offers much better built-in support for dual-channel communication, up to and including being aware of downstream errors and completion. (This enables infinite streams to fulfill a similar purpose to infinite iterators, and it allows Node's behavior of closing source file streams on target error and completion.) It also lacks any inherent "unsubscribe" operation, instead falling back on an eventual cancellation proposal to handle that. So while fundamentally, they're similar, they aren't quite the same and this one is strictly more flexible.

bergus commented 3 years ago

Thanks, that's good to know. I can see how your proposal is much more flexible (and indeed a better abstraction regarding purity), yet it seems to fail on the simplicity aspect. Or I'm just not familiar with the complexity of observables :smile:. What do you think of your chances to find a champion for this proposal?

dead-claudia commented 3 years ago

Or I'm just not familiar with the complexity of observables 😄.

Try implementing an observable library some time. 😉 (It sounds really easy, but it gets hairy quick - there's a lot of hidden complexity.)

What do you think of your chances to find a champion for this proposal?

Haven't gotten around to actively pushing for it, mainly due to lack of time.

bergus commented 3 years ago

Oh, I did, years ago, to play with functional reactive programming. I also implemented various promise libraries, including an algebraic one with support for cancellation (unsubscribing then callbacks) and while I had planned to write another stream library based on pure transducers, I never got from the idea stage to a design that solved all the problems I had thought about. I'll certainly bug you about your solutions in the next days :-) Not including cancellation/unsubscribe would be dealbreaker for me, but I'll open another issue regarding that.