Let me first explain Flux in five seconds.
Instead of mutating your models, any data mutation in your app is described as a plain object describing “what happened” (e.g. { type: LIKED_POST, postId: 42 }) and broadcasted globally. Models (called Stores in Flux) have no setters and change their internal state in response to specific mutation objects (called Actions).
The goal of Flux is to have single source of truth and make it easy to avoid race conditions and cascading updates. If some data is wrong, just repeat the same Actions in the same order, and you'll get the same data in Stores. Very easy to debug.
Now, for Redux.
It keeps the properties of Flux (mutations described as objects), but instead of Stores mutating internal state, it has Reducers—pure functions with (state, action) => state signature. While writing Flux apps, I noticed that the _essence_ of every Store I ever wrote was a reducer function.
It turns out that using pure functions instead of event emitters has many benefits: they are composable (https://gist.github.com/gaearon/d77ca812015c0356654f), it is possible to hot reload their logic (https://camo.githubusercontent.com/5688a6141e6a86baca5d25246...).
I wrote Redux for my React Europe talk about Hot Reloading and Time Travel (https://github.com/react-europe/cfp-2015/blob/master/live-re...). It got popular before I explained _why_ I made it. In my talk I show what kind of powerful devtools it is possible to build on top of Redux. The video of my talk will be up soon, you can check when it appears here: https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A?app....
Also check out my article on the subject: https://medium.com/@dan_abramov/the-evolution-of-flux-framew...
EDIT: THE VIDEO IS UP! https://www.youtube.com/watch?v=xsSnOQynTHs