I can! The idea of unidirectional dataflow is pretty good but the rest of the ideas in Flux aren't as good. For Facebook's implementation, I find making a change requires a bunch of related changes in a bunch of files and I don't like having stores chain.
If you stick all your data into a single big tree/store, you can inspect/serialize and pull off tricks like snapshotting, session recording, simple undo/redo, and time travelling debugging. I do my day to day development in clojurescript (re-frame) so I'm not necessarily up to date but I believe Redux is currently on top for doing this pattern in javascript land.
Redux is "inspired by" Flux, but it's not Flux. One very big (and positive) difference: with Flux each store notifies the React components when it's updated, independently from the other stores.
This means that, if you update two stores with a single action, this will provoke two renders, the first one with inconsistent data between the two stores (in other words, there is no way to update all the stores atomically from the React components point of view).
Redux, instead, updates the whole store, and only then notifies the React components.
That's an important note, indeed. Flux is a pattern as well as a library that represents an implementation of the pattern. Redux is another implementation (and a better one at that, in my opinion.) Specifically regarding Greyrest's concerns about many changes across many files - this can be reduced substantially using Redux.
With all that said, I still wouldn't consider FluxJS a bad place to start, as it provides a very clear example of what Flux really is, but once you understand how the pattern works you'll understand where the implementation is lacking and how Redux can help with that.
