6 ms·

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 R

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 :/

tempsy 7y ago
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.
- banachtarski 7y ago
  2.4 kB minified isn't "tiny" but sure, blame the user.
StuffedParrot 7y ago
I was under the impression redux is basically a message bus plus some sugar. Is that wrong?
- tempsy 7y ago
  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.
  - banachtarski 7y ago
    > 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.
    - lowtolerance 7y ago
      Why implement this functionality from scratch when a tried and tested implementation exists.
      - TrinaryWorksToo 7y ago
        To eliminate a dependency.
        tempsy 7y ago
        The trade off makes no sense
        nennes 7y ago
        So implementing everything from scratch has more benefits than a well maintained and documented dependency?
        TrinaryWorksToo 7y ago
        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.
        nennes 7y ago
        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.
- rudolph9 7y ago
  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!
  - banachtarski 7y ago
    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.
city41 7y ago
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.
- DigitalSea 7y ago
  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.
  - valand 7y ago
    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.
sibeliuss 7y ago
> 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.
- WA 7y ago
  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.

tempsy 7y ago

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.

banachtarski 7y ago
2.4 kB minified isn't "tiny" but sure, blame the user.

StuffedParrot 7y ago

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

tempsy 7y ago
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.
- banachtarski 7y ago
  > 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.
  - lowtolerance 7y ago
    Why implement this functionality from scratch when a tried and tested implementation exists.
    - TrinaryWorksToo 7y ago
      To eliminate a dependency.
      - tempsy 7y ago
        The trade off makes no sense
      - nennes 7y ago
        So implementing everything from scratch has more benefits than a well maintained and documented dependency?
        TrinaryWorksToo 7y ago
        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.
        nennes 7y ago
        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.
rudolph9 7y ago
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!
- banachtarski 7y ago
  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.

city41 7y ago

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.

DigitalSea 7y ago
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.
- valand 7y ago
  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.

sibeliuss 7y ago

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

WA 7y ago
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.