I was learning rx.js for new project in angular 2 and learnt two things: 1. Observables are best when used as Behaviours from classical FRP formulation by C. E

I was learning rx.js for new project in angular 2 and learnt two things: 1. Observables are best when used as Behaviours from classical FRP formulation by C. Elliot. It's a value that's changing over time, and you should only compose it (map, combineLatest, switchMap, merge ...) and push subscriptions to the edges - for example asyncPipe in angular. That makes writing "reactive" (as in Excel cells) code a breeze. Reacting to changes as events (like button click) should be handled with care, with first/takeWhile and so on. But simple cases are still nice looking. 2. Observables are bad as framework for coordination problems. Complex flows of events can easy get out of hand, and suddenly you are passing objects with values and some state through streams or nest switchMaps instead of piping them. Often such code could be written with async/await and would be ten times cleaner. So any code which dealt with changes as events and had branches/state because of that, we rewrote with async/await. Examples are POST/PUT/DELETE requests with logic around authentication/authorization/timeouts. You could model that as stream but when you access closure from outer switchMap it's starts being unwieldy.