What could be the downsides of using Redux instead of Flux
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).
Redux is supporting an immutable concept.
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).
Redux author here!
I'd like to say you're going to make the following compromises using it:
You'll need to learn to avoid mutations. Flux is unopinionated about mutating data, but Redux doesn't like mutations and many packages complementary to Redux assume you never mutate the state. You can enforce this with dev-only packages like redux-immutable-state-invariant, use Immutable.js, or trust yourself and your team to write non-mutative code, but it's something you need to be aware of, and this needs to be a conscious decision accepted by your team.
You're going to have to carefully pick your packages. While Flux explicitly doesn't try to solve “nearby” problems such as undo/redo, persistence, or forms, Redux has extension points such as middleware and store enhancers, and it has spawned a young but rich ecosystem. This means most packages are new ideas and haven't received the critical mass of usage yet. You might depend on something that will be clearly a bad idea a few months later on, but it's hard to tell just yet.
You won't have a nice Flow integration yet. Flux currently lets you do very impressive static type checks which Redux doesn't support yet. We'll get there, but it will take some time.
I think the first is the biggest hurdle for the beginners, the second can be a problem for over-enthusiastic early adopters, and the third is my personal pet peeve. Other than that, I don't think using Redux brings any particular downsides that Flux avoids, and some people say it even has some upsides compared to Flux.
See also my answer on upsides of using Redux.
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.