6

I'm long familear with JavaScript's Promises. I know that today Promises are part of the JavaScript language - since ES6, but long before that they there (and still are) a few different libraries that implemented them.

I've started working recently on a few Angular projects and I was introduced to the concept of Observables (by RxJs).
After some invastegations I understand the basic difference between Observables and Promises:

Observables

  • Passing 0 to N events. Each event can invoke a callback.
  • An observable is Cancelable
  • They are a lot of different methods (Implemented by RxJs team) that can help me read and parse the data like: map, reduce, retry and more.
  • Observables block will be fired only if someone had subscribe to them (otherwise nothing will happen)

Promises

  • Handle a single event, that will invoke a success callback or a failure callback.
  • The ES6 Promises aren't cancelable (for now at least). However different libreries have implemented cancelable promises e.g. BlueBird.
  • Promises block will be fired whether someone had subscribe (using then or catch) to them or not.

My question is not what is the difference between them, but do we actual need Observables, or are they just syntactic sugar? Since the use of Promises is to sync (set in order) an async flow, by telling one block of code to run only when anther block of code had finished it's flow.

  1. Do we really care about handling multiply events, since almost always we would like to react on success or a failure of some flow (like a server request).
  2. The RxJs methods (helper functions) for handling Observables are cool, but not really relevant since you can use a 3rd party library for that behavior (for example instead of using RxJs debounce I can use Lodash _.debounce with a Promise). Of course, each 3rd party library comes with it's additional complexity - but so does RxJs.
  3. Observables being fired only after subscription - this isn't so important - why would we want to have an Observable if nobody is listening (subscribe) to them.

P.S
Please don't read this question and think I have something personal agents Observables, I just want to understand where they shiny the most? and in which cases they are superior then Promises, if ever?

Gil Epshtain
  • 8,670
  • 7
  • 63
  • 89
  • 2
    Observables are Promises on steroids. In theory, everything you can with an Observable you could do with a Promise, but this line of thought can be applied to pretty much anything and it doesn't make too much sense. Observables aren't the answer to everything, but they make managing async data flows much more straightforward. – bugs May 24 '18 at 14:48
  • 4
    I think the real question is not *do we need observables?*. but rather *when do we need observables?* – J. Pichardo May 24 '18 at 14:49
  • 1
    They solve different problems with asynchronicity. I don't really work with Angular a lot, but in React observables give you a more direct line to async data that you need to watch. For example, if you have a a login that is async and you have components all across your app that need to listen to this login change, observables are going to distribute that data better than promises. Callbacks, Promises, async/await and observables all handle asynchronicity and they all have different use cases. – Max Baldwin May 24 '18 at 15:03
  • Possible duplicate of https://stackoverflow.com/questions/50269671/when-to-use-promise-over-observable . *I don't really care about handling multiply events* - then you likely you don't need observables or just aren't aware of the cases where they could be useful (like a stream of DOM events). *but not really relevant since you can use some sort of 3rd party library* - this may be possible somehow but result in messy control flow; observables can provide same improvement over promises as promise can over regular callbacks. – Estus Flask May 24 '18 at 16:26

1 Answers1

3

I do believe that instead of asking do we need observables? we should ask when do we need observables? There are some things that you missed as differences:

  1. Observables are not always asynchronous, some operator like Observable.just are fully synchronous.
  2. There are hot and cold observables, which means some observables only start emitting after you have subscribed to them, HttpClient::get is one of them. While promises evaluate eagerly.

RXJS Observables aim to provide an easy way to do functional reactive programming, while promises are only a way to do asynchronous programming.

Based on that I can say that Observables are not just syntactical sugar for promises, but rather a completely different structure.

J. Pichardo
  • 3,077
  • 21
  • 37
  • Promises can be synchronous as well, for example: `function foo() { return Promise.resolve("someValue"); }`, which will be resolved immediately. – Gil Epshtain May 24 '18 at 15:13
  • @GilEpshtain, that is just theoretical as there is no synchronous way in the standard promise implementation to know synchronously that the resulting promise has resolved. You still need `await` or `then` to actually pull the resolved value, both of which are asynchronous. – trincot May 24 '18 at 15:20
  • @GilEpshtain can you give a practical example? In that `foo` function you wouldn't do `Promise.resolve`. You would more than likely just `return` that value. – Max Baldwin May 24 '18 at 15:22
  • @MaxBaldwin, of curse that in that example I've would just return "someValue", this is just a sily example. But this is exactly what RxJs `just` method is doing - taking a static item and convert it into Observable. http://reactivex.io/documentation/operators/just.html – Gil Epshtain May 24 '18 at 15:31
  • Only because not need to do large chains of promise.then(promise.then(promise.then(promise.then(... make me say: Long live to Observables!! – Eliseo May 24 '18 at 15:51
  • 1
    @Eliseo, One of the porpoises of Promises was to prevent callback nesting, that's why `Promies.then()` also returns a Promise. So instead of nesting Promises you can write `promise.then(...).then(...).then(...)` – Gil Epshtain May 24 '18 at 15:54
  • @GilEpshtain, I referred chains of promises that depending one from the before one. You can't know what promise will be completed the first – Eliseo May 24 '18 at 16:25