React exposes event handlers and setState methods which are seemly mutable and Object Oriented. This is because React is designed for large scale organizations and to be approachable by a broad developer base.

However, once you have certainly complexity in your asynchronous flow, RxJS is a great way to express that.

The interesting part of our experiments (which we designed together with Erik Meijer) can be found here:

https://github.com/facebook/react-page/blob/082a049d2a13b141...

RxJS makes it easy to create abstractions from complex pieces of your async flow. The getStreams method in that example could easily be broken apart into multiple pieces.

This fits very well into the React model and is definitely a great compliment if your organization is already familiar with Rx.

I think it really depends on what you are trying to accomplish. For one thing, a quick peak into React revealed to me that there isn't two-way data binding. I think React and Angular have a lot of friction. They both seem to do well with data binding in their respective ecosystems.

Our (React core) team has experimented with React+RxJS before: https://github.com/facebook/react-page/commit/082a049d2a13b1...

We think that "two-way binding" is actually very, very hard to get right since it flies in the face of the way data flows in a von Neumann program.

Instead, we provide some sugar that lets you get the conciseness of two-way binding but without making it hard to debug or understand performance: http://facebook.github.io/react/docs/two-way-binding-helpers...

But we don't really recommend that for newbies since it's important to understand how the data flows in your program before covering it up with sugar.