Hacker News Reader

Comment by banachtarski | Hacker News Reader

Anecdotally, Redux was absolutely awful to work with. Want a project chockful of middleware to make it passably usable? Use Redux. With all due respect to the Redux team, I simply don't think Redux scales in large applications. The "defaults" are insanely unproductive and encourage developers to cram tons of state in some global pile of state-soup just to claw back conveniences they lost. Monadic transformers and pure state transitions - great ideas in principle, carried way too far here in an ecosystem where the rest of the language and libraries rely on and use mutable state. Not to mention the lost performance, bloat for code that would be considerably shorter, and more disadvantages.

No thanks Redux, no thanks :/

View on HN

> With all due respect to the Redux team, I simply don't think Redux scales in large applications.

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.

Interesting. I didn’t write a big app with Redux, but one potential scaling issue I found is this:

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.

I assume you are referring to React apps? I am curious how you manage state in large React apps. I've yet to find a solution in large/complex apps that I truly like. But in general I have found I prefer "redux-esque" approaches.

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.

The biggest problem with Redux is its complexity. I have seen first hand how Redux scales in large web applications and it sucks. Ask anyone who works at Atlassian and worked on the new Jira, they had to basically break each part of the app up into micro-applications with their own stores because a single-store in Redux for large scale applications does not scale. The navigation sidebar is its own damn React app with Redux store to get around the limitations of a massive store.

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.

Huge react app veteran lead syatem designer here.

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.

I can fully relate to this. Same experience here.

I too am liking RxJS more and more, especially for simple state. I gave up on learning React a few years ago because Redux was just too bonkers.

I find this comment very interesting as I would have said the exact opposite. I have found Rx gets incredibly complicated and opaque incredibly fast. Some of the most nightmarish code I've ever worked with was due to over use and abuse of Rx.

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.

Perhaps you’re using it wrong. It’s tiny. All you do is manipulate a JavaScript object that holds some state that different parts of your app can access. It’s not much more complicated than that.

2.4 kB minified isn't "tiny" but sure, blame the user.

I was under the impression redux is basically a message bus plus some sugar. Is that wrong?

No you’re right. I find the comments deriding Redux as some bloated beast to be amusing...it’s just a thing that lets you read and update a plain javascript object that different parts of your app can access.

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

> it’s just a thing that lets you read and update a plain javascript object that different parts of your app can access

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

Why implement this functionality from scratch when a tried and tested implementation exists.

To eliminate a dependency.

The trade off makes no sense

So implementing everything from scratch has more benefits than a well maintained and documented dependency?

If it's simple, yeah. A redux-type store does not have to be complicated. there are certainly performance optimizations to using redux versus rolling your own, but that would only happen in very large applications.

I agree that you can roll your own store. You'll miss lot of free functionality and the dev tools, but maybe it's not stuff you need.

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.

Yes, I agree. There are trade-offs to be considered. Those are definitely benefits to using Redux, for sure.

I am kind of confused, because I view HN as a strong community in terms of development skill but the comments here on Redux are really surprising..

That’s one way to think of it.

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!

I subscribe to a different philosophy. The whole point of an abstraction is to encourage good behavior. This is how abstractions are able to be leveraged across large teams and organizations to good effect. Abstractions that do the opposite are, in fact, to blame.

"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.

Reply on news.ycombinator.com