Yes, when I first read about Flux (which was after I learned RxJS) I kept thinking that you are essentially writing by hand things that could be generated automatically. It's like going from nested callbacks in early Node.js to Go. :)

I prototyped a decent amount of UI in Cycle and thought that it was great. Using virtualdom with it was really enjoyable and a lot easier to reason about than what is seen in the typical JQuery-based RxJS/Bacon/Kefir examples. However, I found the interaction between exception handling in Cycle and RxJS to be strange at times... maybe I'm just not experienced enough with them yet, but I swear I had some swallowed exceptions that I could never track down. That being said, I feel that this is "the future" (standard disclaimer applies).

Currently I'm using Knockout.js for UI stuff at work and I've found that by maximizing the use of pure computed observables and minimizing mutation of observables (essentially, implementing unidirectional data flow) I can get pretty good results.

Yes, exception handling with Observables, just like with Promises, gets to be a bit more complicated, especially as browser Dev Tools haven't quite caught up to them yet. (With Promises native to ES2015 that's getting fixed and native Observables are tentative for ES2016 or ES2017 which would be great. Also, now that Promises are native, I'm really hoping for a big Node push towards more Promise-friendly APIs.)

The great thing about Observables, though, is that even though exception handling is more complicated as you first learn it: it's a lot more consistent as you get used to it than the callback/event-handler world. That said, I do think Cycle swallowed exceptions it shouldn't have early on (especially without good browser dev tools support) and seems to be getting better at console.loggging them if not propagating them through observable streams as sometimes it should.

My fallback is still Knockout as well. It has served its role, with its very basic observables, very well over the years.

What are some of the pros and cons between RxJS/Cycle and React?

In a nutshell, React encourages you to build applications with unidirectional flow and a mostly immutable style of data handling. React, however, mostly focuses this effort on the View. Cycle extends this encouragement to the entire application architecture and RxJS is its means of doing so in a consistent, reasonable way.

Pros to Cycle over React is that it is truly more "Reactive" in the best of ways, and in a way that is easier to work with (RxJS has a standard set of operators for building and composing reactive Observables that are shared with other platforms).

Cons to Cycle over React is that you lose "the Facebook effect". It's much more a project of love than of big enterprise and so it's a bit harder to learn and a bit more complicated at first glance. (That said, RxJS itself and all the Reactive Extensions libraries have gotten a lot of corporate love from companies as diverse as Microsoft and Netflix.)

http://reactivex.io is a great reference site to learn more about RX. http://cycle.js.org of course also has a very strong explanation of what is and how it expects to work.