The main issue with most applications is state management. This is where Redux get's it right, but I don't think there's much value trying to sum up why Redux s

The main issue with most applications is state management. This is where Redux get's it right, but I don't think there's much value trying to sum up why Redux solves the state management problem in a succinct little diagram. For me, the important things introduced by redux are 1. As single, immutable, source of truth (The Store) 2. Unidirectional data flow 3. Clear separation of concerts (views, actions, reducers, the store). You could stop there and create a nice little diagram, but you need to go further to get the actual benefits. 4. Functional programming (eschew OOP) 5. Higher Order Components (or render prop) 6. Forget DRY, favour simplicity over abstraction 7. Selectors 8. Proper control over side effects (see Redux Sagas) 9. Container components and presentational components. You could still draw a diagram, but it wouldn't be the nice, neat, three box diagram people seem to love so much. Redux is really only viable for Javascript at the moment, but I think it would be an approach worth using elsewhere. Sadly, the model part is hard to get right in compiled, statically typed languages. I'd add to this, I think a thoughtful approach to a redux architecture negates the need for typed Javascript. When your code is functional, your functions are small, your concerns are properly separated, you side effects are wrangled and you state is under total control, Typescript and Flow just make things complicated again.