Don't Blame it on React or Redux

What most people don’t know when they first get into Redux is that, just like React, Redux itself is meant to be simple. And as seen that simplicity is a goal, both React and Redux won’t and don’t want to tell you how to solve everything.

They won’t tell you how to deal with side effects, or what HTTP request library you should use. That’s completely delegated to the JavaScript ecosystem.

React and Redux alone don’t do much for really complex web applications.

React indirectly delegates state management problems to solutions like Flux. On the other hand, Redux, for instance, delegates dealing with async stuff or even the too-much-boilerplate problem that people complain.

But what motivates React and Redux to be that way? Some reasons I can think of are:

• Both libraries are highly focused on their principles, not the built-in stuff. The efficiency of them is on the why and how, not the what.
• They aim to be a great fit for both simple and large applications, so the “plug-in-play” approach is followed. (A framework wouldn’t ever do everything a programmer needs anyway…)
• Diversity of solutions. Because React and Redux are more like “plug-in-play”, the “plugins” (tools, libraries, middlewares) will evolve by themselves. For instance: axios, a HTTP request library, will evolve in parallel to Redux itself – which certainly make things move forward faster!

If your application’s state is messy, don’t blame it on React. If you find yourself writing too much boilerplate, don’t blame it on Redux. React and Redux don’t really do much, but this is by design.

React is awesome not just because it makes it possible to turn a large and complex application into simple components.

Redux is awesome not just because it makes it effortless to deal with and share state throughout an application.

They’re also awesome because of their great and diverse ecosystem. So, when you buy into React or Redux, it’s better for you to buy into their ecosystem too.