I keep wanting to dip my toes in and I get the gist of why you'd use React (less so Flux), but there's so many frameworks to choose from that I get nervous about picking the wrong horse and find myself waiting until the dust settles.
Absolutely. At first I was excited that there was so much activity. Simultaneously, it intimidates many engineers I talk to because of how much fragmentation there is.
Thankfully, the footprint of each framework is relatively small. I'd try to pick the one that seems to be the least encroaching (e.g. not using tons of custom components, something fairly agnostic about underlying data structure/data fetching methods). That way, if the tide suddenly changes, you're not buried up to your toes in messy, dying code.
You can also get by with React on its own! We've got a few areas in some of our Backbone apps where we've just decided to use raw XHR requests to fetch data (and nothing wrapping around the objects themselves).
So the TLDR is that I don't have a good panacea of a Flux library to recommend, but that shouldn't stop you from investigating React as a view mechanism in your applications.
Try to use React without anything just to get a feel for it and then you will find out by yourself what it needed to make it work and what are its good and bad points.
Working with big frameworks is too opaque and you are restricted to do what they deem good.
I tend to agree. Even as an author of one of the Fluxes (Fluxii?) mentioned, I still think this is the best approach. All of implementations I've seen simply formalize patterns the author was repeating on multiple projects.
(There's also know obligation to use them, the joy of OSS!)
I keep wanting to dip my toes in and I get the gist of why you'd use React (less so Flux), but there's so many frameworks to choose from that I get nervous about picking the wrong horse and find myself waiting until the dust settles.