Agreed, definitely didn't mean to pigeonhole RxJS. There are so many times I've been saved in the last year from async bugs because of RxJS. That said, it took

Agreed, definitely didn't mean to pigeonhole RxJS. There are so many times I've been saved in the last year from async bugs because of RxJS. That said, it took me almost 6 months of practice to be able to make my code readable and use it scalably. I've actually come up with a solid rule of thumb for when it makes sense to use: If you have 2 async streams of events or data, that's at least 4 success scenarios you have to code for: 1. A has emitted, B hasn't 2. B has emitted, A hasn't 3. A and B haven't emitted 4. A and B have both emitted Now at 2 sources (and ignoring the error cases) that's right on the edge of being able to mentally model it and not forget a case, but at 3 you have 9 cases, at 4 you have 16, etc. etc. The branches and code you'd be creating to deal with this situation procedurally would be far more unreadable compared to the RxJS syntax. It was always a complex problem.