Very much disagree. Redux, to it's, credit, almost made development boring to me in the sense that we had an unreasonably large application that could scale and scale and scale without any concern whatsoever. I've worked with other patterns and libraries since and nothing compares to how easy it was for our team (of varying degrees of experience) to jump in anywhere and make additions that made sense through time. And like the author of the article mentions, all of our devs grew in general because of what they learned from it's patterns / concepts.

You kind of have to think about the structure of your state tree beforehand. If you later discover that you sliced your state in several sub-trees with respective reducers, but the reducer of sub-tree A now needs to get some info from sub-tree B, things can get confusing.

Or put another way: if you think parts of your state are independent from other parts and this later turns out to be wrong, you need to refactor quite a bit or have to live with an improperly separated state.

I guess scalability depends a lot on the nature of changing requirements and how experienced you are to define the state tree. This is actually something where I see the biggest learning curve.

For example: say you pull data from your database. This could be considered the normalized state and everything else is just derived from that state. However, in your UI, it doesn’t make sense to work directly with the original normalized DB state, but some kind of semi-normalized intermediate state.

Furthermore: you could put computed/derived state directly in the state tree, or use something like the Reselect library.

Since there are endless possibilities to design this, it can be tough to learn any of this. Most tutorials also deal with very simplistic state trees.

Redux itself has had a pretty rocky road. From its early days of lots and lots of boilerplate, to "ducks" and all kinds of other things over the years. I think the problem was Redux has always been nice in theory, but getting it nice in practice has literally been years of people trying all kinds of things. I think most people's opinions of Redux are largely shaped on at what point they jumped in.

I am having some decent success with the new redux-toolkit. It's finally an opinionated redux offering, which is nice to see. I've also been exploring mobx-state-tree and rematch, and have even had some success with using context coupled with useReducer for a very lightweight redux approach.

If you're looking for a Redux alternative, look no further than RxJS. You get all of the power of Redux without the complex concepts to learn. The Aurelia Store plugin is a great example of using RxJS for state management (it also works with Redux dev tools). A lot of Angular developers will also tell you they use RxJS for state and attest how great it is.

I have seen way too many sloppy poorly performing applications using Redux to know that it is its own worse enemy. The complexity makes for a terrible result in many developer hands.

I'm certainly open to seeing if Rx can be used in a nice way. But so far my experience has been very negative.

But with that said, I also feel you can name any state management system (any one at all) and you will find people who love it, and people who loathe it. I feel in general that state management is in many ways an unsolved problem.

Ended up not using redux after our previous project failing to scale development-wise (it gets harder to put feature in it). Using unstated, it freed developers from god object paradigm introduced by redux's single global connect() function.

Then we did the same, breaking apart states and putting them in the proper scope.

Also, we also removed state from inter-component operations which doesn't really need state, the ones developer usually workaround using global redux states. We replaced it with custom made event sourcing / message passing library.

Think of it as using rabbitMQ but it is running inside your javascript app.

Things get so much simpler after that. Features can be put it a lot faster. Combined with io-ts, it also support almost 100% TypeScript type checks both on compile-time and run-time.

No blank page issue ever since even without a single React ErrorBoundary and minimum unit-test.

People making things more complicated than they are is really a disease in the dev community.

Doesn't require a library, let alone an ecosystem of libraries.

I also agree that introducing a dependency at every opportunity comes with serious drawbacks.

Every situation is unique of course. In my case: At work, I value code that is more standardised so that I get less bugs, documentation / best patterns and crucially easier on-boarding process. For a personal project, I would definitely consider rolling out my own implementation, even just for the learning it comes with.

The op of this thread is not wrong but the misuse has more to do with the level of discipline the average JavaScript developer employs than anything.

With great power comes great responsibility!

"Good interfaces are easy to use properly, and hard to use improperly" should be the bread-and-butter mantra of any library author, and Redux violates this repeatedly.