Observables are more different from promises than they are similar.
Learning Observable By Building Observable
Ben Lesh

Could you see Promise as an Observable? Like Promise is a Stream? With at most one event to occur.

I mean conceptually, not tied to specific implementation details. The Promise also wraps the data source. You could make it return a cancellation function, in principle, but it seems people don’t care about cancelling promises that much. Garbage collecting the promise object instead seems to do the job with no memory leaks.

Instead of returning a function, a Promise returns an object, which is essentially the same as a collection of functions (aka methods), instead of single function. I might be missing something, but in comparison, having several functions instead of one feels more powerful and flexible. That also makes the Promise very simple to use. Attaching observers via then and error handlers via error or catch is convenient, because you can pass plain functions or Promises, whereas passing Observers requires them to conform to specific API. Also due to the explicit attaching mechanism, the problem of the memory leaks is not even present.

I understand that Observables are meant to deal with more general cases, but it would be nice to have them more similar to Promises in the specific use cases of the Promises.

For instance, instead of limiting to returning single function, why not returning objects with more methods like then and catch ? That would make Observables more accessible or “ergonomic” as you say to people already familiar with Promises.

I might be missing something, but it would seem writing it as easy as


would make the Observables easy to use. Would it not?

Muticast — would be nice if you could explain what exactly you mean here by this term.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.