6 ms·

Hey, I like your version too. I’m digging these simple state libraries. Really proves just how absurd Redux was when you finally see the simple solution.

franciscop 6y ago
I believe Redux is good when you have 3+ people working on the same project front-end, and absolutely necessary when you have 10+. This makes it work great with the Facebook, Airbnb, etc. of the world. Which is totally fine, but not your everyday problem for the rest of us! I'm very happy to see all of these versions pop up as well.
- runawaybottle 6y ago
  What makes that objectively true? I’m looking at these APIs, and at least two of these solutions are plain better design. What about this would get worse with more engineers or higher caliber engineers that Redux clearly avoids?
  - franciscop 6y ago
    It formalizes how data is created, accessed and modified. Instead of multiple places trying to modify some specific data ad-hoc and with possible collisions/changes, now you have a mores strict way of dealing with data. Basically the Flux architecture. See from 10:20: https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw
    - aenero 6y ago
      I see what you're saying here, and actually agree at some level. But there is always an alternative, IMHO. If the project has a good code structure and follow equally good coding standards and review process, using simple un-opinionated/flexible libraries would not be a liability with "scale" (in terms of team/project size). And there's one advantage of simpler approaches for growing teams: faster/easier onboarding. Let's face it, even good React/Redux developers can understand simpler code faster. Just an alternative thought. But I completely get your point.
    - runawaybottle 6y ago
      Ok, so what are the actions/reducers nonsense about? I’m just not seeing the argument here, and I’ve been on multiple redux applications on teams of various sizes. We always seem to create layers of indirection to do the simplest possible state update. We adopted Dan Abramov’s mental model, and my god, it was a labyrinth.
      - acemarke 6y ago
        You might want to read my "Tao of Redux" posts and Dan's "You Might Not Need Redux" post, which explain why Redux was designed the way it is: - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... Ultimately, it's about putting a deliberate separation between "what happened" in the UI and "how the state is updated", writing as much of your state update logic as pure functions, and being able to use that indirection to enable tracing state updates over time via the DevTools. Also note that our official Redux Toolkit package is now the standard recommended way to write Redux logic, and it simplifies most of the Redux code you'll write: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
        runawaybottle 6y ago
        I think you guys should take a more honest retrospective on an age old topic of ‘Intent versus Impact”. The truth of the story was that community was desperately looking for a solution to global state to avoid prop drilling. No amount of technical virtuosity, or cop outs to a half assed flux architecture that fundamentally mimics model-view-controller or a pub/sub pattern will be satisfiable to anyone with critical thinking ability. The kids had one job, get some global state available to the app, and they managed in their bravado to pack in ‘addons’, or in sales terms, they ‘up-sold’, that $40 hdmi cable along with your new $1600 television. Dan packaged his extra bullshit (the reducer pattern) over to a desperate group that had nowhere else to turn for a global state solution. Celebrity and hero worship was one of the premier sins in all of this. The guy didn’t know what the fuck he was doing and no one called him out on it. Certainly we are not going to marvel at the fact that he is a React core developer. Bad ideas are bad ideas, regardless of the current class that ordains it. For this, I am depressed, and will continuously antagonize the Redux team for the damage they caused the entire community. The Redux team owes a debt. Rewrite your library so that the api is 5 lines at max. Replace your conceptions, seek forgiveness for the sin, and let it rest. Until then, don’t peddle your Frankestein ever again anywhere, you all had plenty of time in the limelight and quite frankly - you weren’t good enough. Like what is the redux-toolkit? Do you guys lack the conviction to decide what the api is or isn’t? With all that said, if you don’t understand what I’m saying, then mapDispatchToProps or mapsTateToFuckYou, connect everything to nonsense, and I suppose in your new bullshit, createSlice to shut up already. You guys can’t write an api if your life depends on it. And I swear to god, if I hear about the stupid Ducks pattern ... I just can’t anymore. Anyways, I’d prefer never to punch down if I can avoid it. The redux/abramov/constituents of the react community became the Zeitgeist of the Javacript community. Paragons. And no one stood up to them and behind the bullshit is a clusterfuck of shitty apps. You guys ain’t a small agenda, and I expect the fight to continue.
qudat 6y ago
Simple state libraries are great for simple web apps, not for massive, enterprise-level applications. As someone who regularly investigates alternatives to redux, it still sits at the top of state management. These intro how-to comparisons don’t do redux justice because being simple to use is not the stated goal of redux. Large scale, maintainable, and traceable code is the primary goal of redux. When you allow anything to update your state with zero form of traceability, you’ll start to see the cracks in these simple designs. Are these new state management libraries easy to use? Sure, but what happens when you have tens of thousands (even hundreds of thousands) of lines of code to deal with and then add major refactoring objectives in the pipeline? Like others have mentioned, if you are using redux for a simple to-do app, then its design principles are probably not as valuable. It’s like thinking about time complexity for algorithms, at a small enough N, even slow algorithms can compete, but as you increase N, some algorithms become untenable.
- runawaybottle 6y ago
  You are not the only one debugging large apps. How does the wider world of programming debug stuff without actions and reducers? It’s crazy how the Redux people either always appeal to authority (‘my app is bigger than yours’) or can’t say anything more than ‘I just like it’. And to play the rhetorical game, what happens when you have hundreds of thousands of lines of insane Redux code where you have lost all sense of the state tree and need to mentally cordon off one single piece of it to not go insane? Kind of like how libraries like this are already doing it. So here is my challenge to you. Spec out an app that you believe can only be solved with Redux at scale (or rather, highlight the areas of the app that absolutely benefit from Redux, but please provide as detailed a spec as you can if you have the time, or care for that matter). I’d love to hear about this incredible web app.
  - qudat 6y ago
    The reason is because the problems that surface at scale are difficult to illustrate in a comparison blog, which is the foundation for all the rants against redux. Redux is not complex, contrary to popular belief. The core code can be written in 100 LoC. The real downside to redux is not the boilerplate that is required to set it up or the number of concepts to learn, instead it’s how easy it is to do it incorrectly. The redux maintainers have spent the last few years not making changes to the core library, but figuring out conventions and helper libraries to make it more clear what you should (eg normalize state) and should not (put every piece of state) in your redux store. No offense but the spec exercise seems like a waste of both of our time. No amount of talking about an app can illustrate the code organization at scale.

franciscop 6y ago

I believe Redux is good when you have 3+ people working on the same project front-end, and absolutely necessary when you have 10+. This makes it work great with the Facebook, Airbnb, etc. of the world. Which is totally fine, but not your everyday problem for the rest of us! I'm very happy to see all of these versions pop up as well.

runawaybottle 6y ago
What makes that objectively true? I’m looking at these APIs, and at least two of these solutions are plain better design. What about this would get worse with more engineers or higher caliber engineers that Redux clearly avoids?
- franciscop 6y ago
  It formalizes how data is created, accessed and modified. Instead of multiple places trying to modify some specific data ad-hoc and with possible collisions/changes, now you have a mores strict way of dealing with data. Basically the Flux architecture. See from 10:20: https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw
  - aenero 6y ago
    I see what you're saying here, and actually agree at some level. But there is always an alternative, IMHO. If the project has a good code structure and follow equally good coding standards and review process, using simple un-opinionated/flexible libraries would not be a liability with "scale" (in terms of team/project size). And there's one advantage of simpler approaches for growing teams: faster/easier onboarding. Let's face it, even good React/Redux developers can understand simpler code faster. Just an alternative thought. But I completely get your point.
  - runawaybottle 6y ago
    Ok, so what are the actions/reducers nonsense about? I’m just not seeing the argument here, and I’ve been on multiple redux applications on teams of various sizes. We always seem to create layers of indirection to do the simplest possible state update. We adopted Dan Abramov’s mental model, and my god, it was a labyrinth.
    - acemarke 6y ago
      You might want to read my "Tao of Redux" posts and Dan's "You Might Not Need Redux" post, which explain why Redux was designed the way it is: - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... Ultimately, it's about putting a deliberate separation between "what happened" in the UI and "how the state is updated", writing as much of your state update logic as pure functions, and being able to use that indirection to enable tracing state updates over time via the DevTools. Also note that our official Redux Toolkit package is now the standard recommended way to write Redux logic, and it simplifies most of the Redux code you'll write: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
      - runawaybottle 6y ago
        I think you guys should take a more honest retrospective on an age old topic of ‘Intent versus Impact”. The truth of the story was that community was desperately looking for a solution to global state to avoid prop drilling. No amount of technical virtuosity, or cop outs to a half assed flux architecture that fundamentally mimics model-view-controller or a pub/sub pattern will be satisfiable to anyone with critical thinking ability. The kids had one job, get some global state available to the app, and they managed in their bravado to pack in ‘addons’, or in sales terms, they ‘up-sold’, that $40 hdmi cable along with your new $1600 television. Dan packaged his extra bullshit (the reducer pattern) over to a desperate group that had nowhere else to turn for a global state solution. Celebrity and hero worship was one of the premier sins in all of this. The guy didn’t know what the fuck he was doing and no one called him out on it. Certainly we are not going to marvel at the fact that he is a React core developer. Bad ideas are bad ideas, regardless of the current class that ordains it. For this, I am depressed, and will continuously antagonize the Redux team for the damage they caused the entire community. The Redux team owes a debt. Rewrite your library so that the api is 5 lines at max. Replace your conceptions, seek forgiveness for the sin, and let it rest. Until then, don’t peddle your Frankestein ever again anywhere, you all had plenty of time in the limelight and quite frankly - you weren’t good enough. Like what is the redux-toolkit? Do you guys lack the conviction to decide what the api is or isn’t? With all that said, if you don’t understand what I’m saying, then mapDispatchToProps or mapsTateToFuckYou, connect everything to nonsense, and I suppose in your new bullshit, createSlice to shut up already. You guys can’t write an api if your life depends on it. And I swear to god, if I hear about the stupid Ducks pattern ... I just can’t anymore. Anyways, I’d prefer never to punch down if I can avoid it. The redux/abramov/constituents of the react community became the Zeitgeist of the Javacript community. Paragons. And no one stood up to them and behind the bullshit is a clusterfuck of shitty apps. You guys ain’t a small agenda, and I expect the fight to continue.

qudat 6y ago

Simple state libraries are great for simple web apps, not for massive, enterprise-level applications. As someone who regularly investigates alternatives to redux, it still sits at the top of state management. These intro how-to comparisons don’t do redux justice because being simple to use is not the stated goal of redux. Large scale, maintainable, and traceable code is the primary goal of redux. When you allow anything to update your state with zero form of traceability, you’ll start to see the cracks in these simple designs. Are these new state management libraries easy to use? Sure, but what happens when you have tens of thousands (even hundreds of thousands) of lines of code to deal with and then add major refactoring objectives in the pipeline? Like others have mentioned, if you are using redux for a simple to-do app, then its design principles are probably not as valuable. It’s like thinking about time complexity for algorithms, at a small enough N, even slow algorithms can compete, but as you increase N, some algorithms become untenable.

runawaybottle 6y ago
You are not the only one debugging large apps. How does the wider world of programming debug stuff without actions and reducers? It’s crazy how the Redux people either always appeal to authority (‘my app is bigger than yours’) or can’t say anything more than ‘I just like it’. And to play the rhetorical game, what happens when you have hundreds of thousands of lines of insane Redux code where you have lost all sense of the state tree and need to mentally cordon off one single piece of it to not go insane? Kind of like how libraries like this are already doing it. So here is my challenge to you. Spec out an app that you believe can only be solved with Redux at scale (or rather, highlight the areas of the app that absolutely benefit from Redux, but please provide as detailed a spec as you can if you have the time, or care for that matter). I’d love to hear about this incredible web app.
- qudat 6y ago
  The reason is because the problems that surface at scale are difficult to illustrate in a comparison blog, which is the foundation for all the rants against redux. Redux is not complex, contrary to popular belief. The core code can be written in 100 LoC. The real downside to redux is not the boilerplate that is required to set it up or the number of concepts to learn, instead it’s how easy it is to do it incorrectly. The redux maintainers have spent the last few years not making changes to the core library, but figuring out conventions and helper libraries to make it more clear what you should (eg normalize state) and should not (put every piece of state) in your redux store. No offense but the spec exercise seems like a waste of both of our time. No amount of talking about an app can illustrate the code organization at scale.