https://github.com/facebook/flux is this the flux it's for?
It seems opaque to me at this stage. It reminds me of when Google released Polymer. There was a lot of generic stuff - but no elevator pitch.
Explain to me in 30 seconds what's flux and where it sits?
Flux is an architecture pattern for applications where a lot of logic can run on the client. Its goal is to disconnect changes to state (the "model" in MVC terms) from the effect that should have on the view. This assumes that the view is a layer that can cheaply update itself without knowing what part of the state changes - a full "re-render" should be cheap and effective. React is a library that allows this.
Once the view can update itself without knowing what state changed, one side of the disconnect between state and UI has been solved. The other side is how to manage state when user actions change it.
When the model is a big blob of mutable data, this is easy: just update whatever you want to update, trigger a full re-render of the view and be done with it. But this has two disadvantages: first, it's often difficult to serialize this model and send it over the wire, which means prerendering on the server for snappy startup times is difficult. Second, people often prefer the model layer to be built of immutable data, because that makes React re-rendering faster.
Flux tries to make working with serializable, immutable data easier by introducting what they call a "unidirectional data flow": user actions go into a "dispatcher", which in term knows which little sub-part of the model, called a Store, wants to turn that action into a data change. The stores, in turn, tell the view to re-render and that's it. The view can query the stores but not change the data in them: that's done only by sending actions through the dispatcher.
The core insight of Flux is that dealing with immutable data is pretty easy if you split the model up into a limited number of simple "Stores", the granularity of which determines much of how well Flux works for you. If you manage to get them not too big and not too small, dealing with immutable data is not difficult anymore and React gets snappy updates. And serializing immutable data to JSON is pretty easy, because it's guaranteed to be a tree, so prerendering both the HTML and the initial dataset on the server is a done deal.
Sorry, not 30 seconds. Does this help at all?
Personal commentary: I'm not convinced that Flux is the final solution. Before Flux was popular, I led a React team with a model layer that was plain old mutable JavaScript objects, and it worked remarkably well. It was a big cyclic graph of objects that all referred to one another. Typical oldschool OO data model design. The big disadvantage was that re-rendering was slower, but IMHO we need to find a better solution around that.
The guys who invented React said "what? all that spaghetti code just to keep model and HTML in sync? i just want to rerender every time just like we used to do with PHP on the server! i'm going to find a workaround" and invented the virtual DOM. In the same spirit, there has to be a way to make mutation of state simpler and still be fast and support universal ("isomorphic") apps. Mutable state is rather unpopular these days, but if there's one place where it shines, it's UI development.
I'm feeling this in a back-end app and I'm wondering whether I can make use of some of these concepts to make things more manageable.