as far as i know, redux is inspired by flux. flux is an architecture like mvc (model view controller). facebook introduce the flux due to scalability problem when using mvc. so flux is not an implementation, it just a concept. actually redux is the implementation of flux.

redux require discipline regarding to immutability. something i can recommend is ng-freeze to let you know about any accidental state mutation.

i prefer using redux as it uses one store which makes state management much easier compare to flux, also redux devtools it's really helpful tools which let you see what you doing with your state with some useful data and it's really inline with react developing tools.

also redux has got more flexibility using with other popular frameworks like angular. anyway, let's see how redux introduces himself as a framework.

redux has three principles which can introduced redux very well and they are the main difference between redux and flux also.

single source of truth

the state of your whole application is stored in an object tree within a single store.

this makes it easy to create universal apps, as the state from your server can be serialized and hydrated into the client with no extra coding effort. a single state tree also makes it easier to debug or inspect an application; it also enables you to persist your app's state in development, for a faster development cycle. some functionality which has been traditionally difficult to implement - undo/redo, for example - can suddenly become trivial to implement, if all of your state is stored in a single tree.

console.log(store.getstate())

/* prints
{
  visibilityfilter: 'show_all',
  todos: [
    {
      text: 'consider using redux',
      completed: true,
    },
    {
      text: 'keep all state in a single tree',
      completed: false
    }
  ]
}
*/

state is read-only

the only way to change the state is to emit an action, an object describing what happened.

this ensures that neither the views nor the network callbacks will ever write directly to the state. instead, they express an intent to transform the state. because all changes are centralized and happen one by one in a strict order, there are no subtle race conditions to watch out for. as actions are just plain objects, they can be logged, serialized, stored, and later replayed for debugging or testing purposes.

store.dispatch({
  type: 'complete_todo',
  index: 1
})

store.dispatch({
  type: 'set_visibility_filter',
  filter: 'show_completed'
})

changes are made with pure functions

to specify how the state tree is transformed by actions, you write pure reducers.

reducers are just pure functions that take the previous state and an action, and return the next state. remember to return new state objects, instead of mutating the previous state. you can start with a single reducer, and as your app grows, split it off into smaller reducers that manage specific parts of the state tree. because reducers are just functions, you can control the order in which they are called, pass additional data, or even make reusable reducers for common tasks such as pagination.

function visibilityfilter(state = 'show_all', action) {
  switch (action.type) {
    case 'set_visibility_filter':
      return action.filter
    default:
      return state
  }
}

function todos(state = [], action) {
  switch (action.type) {
    case 'add_todo':
      return [
        ...state,
        {
          text: action.text,
          completed: false
        }
      ]
    case 'complete_todo':
      return state.map((todo, index) => {
        if (index === action.index) {
          return object.assign({}, todo, {
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combinereducers, createstore } from 'redux'
let reducer = combinereducers({ visibilityfilter, todos })
let store = createstore(reducer)

for more info visit here

one of the largest benefits in using redux over the other flux alternatives is its ability to reorient your thinking towards a more functional approach. once you understand how the wires all connect you realize its stunning elegance and simplicity in design, and can never go back.

flux and redux . . .

redux is not a pure flux implementation but definitely inspired by flux. biggest difference is that it uses a single store that wraps a state object containing all the state for your application. instead of creating stores like you'll do in flux, you'll write reducer functions that will change a single object state. this object represent all the state in your app. in redux you will get the current action and state, and return a new state. that mean that actions are sequential and state is immutable. that bring me to the most obvious con in redux (in my opinion).

why immutability?

there are few reasons for that:
1. coherence - store's state is always being changed by a reducer so it's easy tracking who change what.
2. performance - because it's immutable, redux only need to check if previous state !== current state and if so to render. no need to loop the state every single time to determined rendering.
3. debugging - new awesome concepts like time travel debugging and hot reloading.

update: if that wasn't persuading enough, watch lee byron excellent talk about immutable user interfaces.

redux require a developer(s) discipline through the codebase/libraries to maintain this idea. you'll need to make sure you pick libraries and write code in a non-mutable manner.

if you'd like to learn more about the different implementation of flux concepts (and what works best for your needs), check out this useful comparison.

after said that, i must admit that redux is where js future development is going to (as for writing these lines).

both redux and flux require a considerable amount of boilerplate code to cover many common patterns, especially those that involve asynchronous data fetching. the redux documentation already has a handful of examples for boilerplate reduction: http://redux.js.org/docs/recipes/reducingboilerplate.html. you could get everything you might need from a flux library like alt or fluxxor, but redux prefers freedom over features. this could be a downside for some developers because redux makes certain assumptions about your state that could be inadvertently disregarded.

the only way for you to really answer your question is to try redux if you can, perhaps in a personal project. redux came about because of a need for better developer experience, and it is biased towards functional programming. if you aren't familiar with functional concepts like reducers and function composition then you might be slowed down, but only slightly. the upside for embracing these ideas in data flow is easier testing and predictability.

disclaimer: i migrated from flummox (a popular flux implementation) to redux and the upsides far outweigh any downsides. i prefer much less magic in my code. less magic comes at a cost of a little more boilerplate, but it's a very small price to pay.