Redux is not needed any but it still has some tiny advantages such as performance optimization, for instance when compared to the context API in large applications
I'm not in a Redux fancamp but Anton is right - ecosystem matters. That's the reason why some technologies are still used so much despite their flaws (I'm not saying this for Redux though).
Just to provide a contrast to some of the other comments on this comment, Redux is not complex in the slightest but it often requires a certain amount of boilerplate. It's a great option, but there are also a range of other equally good options.
Nah, a good developer can write great code even with the most rudimentary library. There's no need to have "camps" in this petty topic. Relying too much on "tools" is just being weak. lol.
Saying that something is the best for everything would yield nothing but an unproductive debate. There is no such thing as one-size-fits-all in libraries, otherwise everybody would just use Redux for everything. Even the author of Redux himself does not recommend that.
Someone out there could be searching for the "simplest" instead of the "best", and there's nothing wrong with that.
Trashing other libraries in favor of your own favorite is not exactly helping anyone. I hope you actually looked at the library first before concluding that it is only "good for increment-decrement examples", but thanks for your feedback in any case.
Yes, sure, stability/scalability trumps simplicity,
but whats about a simple AND scalable state management approach?
SimpleR State is a singleton state management approach,
and it's (in my opinion) pretty simple, scalable, and maintainable.
I have created a State Manager (AgileTs) with a similar concept,
and as far as I can tell, it is extremely scalable if used correctly.
In most of the cases Redux is not needed anymore, unless the application is really huge. Not just a simple crm but a large application with huge amount of logic. Otherwise, it is simpler to use things like apollo (if you have GraphQL), react-query, Recoil or Jotai. Or just write custom hooks. Redux is too complex with a need to create action creators, actions, reducers, then connect them to store. If you need to affect different parts of the store it becomes too sophisticated.
The combination of Redux and redux-observable looks impossible for junior developers. It is powerful but so overcomplicated.
You should take time to consider what problems you're actually trying to solve, and choose tools that actually solve the problems you're dealing with.
That's what I'm saying. Use the right tool. Before using Redux make sure you really need it.
My very rough estimates of React ecosystem state management market share are
So these are just some random statistics from some random guy on the internet. Not saying he is not right though.
Most devs still think that Redux is the only state management library and pick it just because they think so and don't want to learn new technologies. I talked to my colleagues and they simply don't want to consider using other libraries because they believe "Redux is Redux and other libraries are meh". They even didn't try those libraries. Some React devs still use class components over functional with hooks because:
projects are legacy and nobody is going to refactor them
devs keep classes on purpose because they prefer them
Coming back to my original idea. Use the right tool and be up-to-date with modern technologies.
FWIW, I'm the primary Redux maintainer. So, sure, feel free to take my comments with a grain of salt, but A) I happen to be an expert on this topic, B) I spend most of my time answering questions about when it makes sense to use Redux, and C) I'm definitely not just "a random guy on the internet" :)
I've established a pretty solid track record of being straightforward and unbiased in my evaluations and responses:
Mark is a breath of fresh air, right?! He'll forever be at the top of my list for people that I trust to always deliver an objective take on something, regardless of stake or emotion.
Look, I didn't want to offend you and I partially share your opinion. I'm just saying that often Redux is popular because devs don't want to consider any changes in their existing apps and don't want to try new tools in their new projects.
Recently, I have been working on a project that uses Redux but it is just about keeping fetched data. Yes, it is a lot of data but Redux is not needed for that.
Even when it is needed to store some state maybe a custom hook is enough. Tools like Recoil and Jotai (or Xstate if your choice is state machines) can keep the state and even transform it (hello Reselect).
Coming back to my point:
Use the right tool. Before using Redux make sure you really need it.
I am a software developer and writer with expertise on Laravel and the blade templating engine, the knowledge of which includes HTML, CSS, JAVASCRIPT. I am also into WordPress.
I think you're very right. As soon as one becomes a react developer, the very next expectation everyone seems to have of you is that you must understand and use redux. Obviously, redux isn't the only state management tool out there. There are easier and less complex tools out there. Once you get in that for most of your projects you get to use any of the options, like Recoil, useContext and so many others, its like a brush of possibilities.
To provide some additional context (no pun intended) to Vladamir's comments...
I'm sure some developers are still using Redux because they "don't want to consider any changes in their existing apps and don't want to try new tools in their new projects." Familiarity is an advantage but ought to be weighed against the benefits which alternatives would bring. Sensible developers won't only use Redux because it's familiar, but novelty should not be the only reason to switch.
I'm still someone who uses Redux because I've not yet tried a state management library which provides enough benefit to justify the switch. If I want to tell the people that I work with that we're making the switch away from Redux, I'll be talking to smart people, and they'll rightly want to know why it is that we're making this switch. Right now I don't feel like I could provide an adequately watertight answer.
For all the same reasons, if someone already knows a library like Recoil, they are right to consider why they would switch to Redux, when they know a perfectly good solution to the same problem.
"The state manager is not about being simplest, it's about being scalable and having good devtools"
I long ago realised the quest for scaleability is death to so many start ups.
You have to move fast and break things, and for god sake ship. I've seen so many good startups die to giant complexity balls bourne out of "Well what happpens when we have 20 million customers". Cool eggs, but focus on getting A customer first, because for every month your bizarely overcomplicated serverless nosql redux firebase hellmachine remains in development hell, the less enthusiastic investors become about funneling more junk money into your scheme, and then blam out of the blue someone with a simpler but functional product hits the market and eats your market becore your even laiunched. Game over.
I completely agree. In the highly competitive industry today, ship fast is the goal. I would bet, if we look at the source code of the early versions of those highly successful apps out there, the perfectionists among us would have a lot of negative things to say about them. But at the end of the day, those apps have beaten the hell out of over-engineered apps that just took too long to launch.
I like your point about "before even worrying about being able to serve millions of customers, focus on getting that first customer first" 😀. Although to be fair to the original comment, "scalable" in this context is probably referring to scaling with the growing feature set of the web app. But your idea still translates well to this context—"before worrying about delivering lots of features, focus on shipping out a minimum viable product first with one killer feature".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The state manager is not about being simplest, it's about being scalable and having good devtools. Nothing better than Redux in that sense.
Your state manager is good only for increment-decrement examples.
You clearly are in the Redux fancamp and it is the only thing you know... Redux is not even needed anymore
Redux is not needed any but it still has some tiny advantages such as performance optimization, for instance when compared to the context API in large applications
I would also never use Context alone for big apps but instead Recoil over Redux
I'm not in a Redux fancamp but Anton is right - ecosystem matters. That's the reason why some technologies are still used so much despite their flaws (I'm not saying this for Redux though).
Just to provide a contrast to some of the other comments on this comment, Redux is not complex in the slightest but it often requires a certain amount of boilerplate. It's a great option, but there are also a range of other equally good options.
I found this, savage
What's all this commotion lol. Even the Redux guy is here.
Day is not a day without state management drama!
Nah, a good developer can write great code even with the most rudimentary library. There's no need to have "camps" in this petty topic. Relying too much on "tools" is just being weak. lol.
Saying that something is the best for everything would yield nothing but an unproductive debate. There is no such thing as one-size-fits-all in libraries, otherwise everybody would just use Redux for everything. Even the author of Redux himself does not recommend that.
Someone out there could be searching for the "simplest" instead of the "best", and there's nothing wrong with that.
Trashing other libraries in favor of your own favorite is not exactly helping anyone. I hope you actually looked at the library first before concluding that it is only "good for increment-decrement examples", but thanks for your feedback in any case.
Yes, sure, stability/scalability trumps simplicity,
but whats about a simple AND scalable state management approach?
SimpleR State is a singleton state management approach,
and it's (in my opinion) pretty simple, scalable, and maintainable.
I have created a State Manager (AgileTs) with a similar concept,
and as far as I can tell, it is extremely scalable if used correctly.
I've created a Style Guide for large applications using such a singleton State Management approach:
agile-ts.org/docs/style-guide#-ins...
In most of the cases Redux is not needed anymore, unless the application is really huge. Not just a simple crm but a large application with huge amount of logic. Otherwise, it is simpler to use things like apollo (if you have GraphQL), react-query, Recoil or Jotai. Or just write custom hooks. Redux is too complex with a need to create action creators, actions, reducers, then connect them to store. If you need to affect different parts of the store it becomes too sophisticated.
The combination of Redux and redux-observable looks impossible for junior developers. It is powerful but so overcomplicated.
FWIW, Redux is still used by about 50% of React apps, and is the most widely used state management tool for React apps by a large margin.
You should take time to consider what problems you're actually trying to solve, and choose tools that actually solve the problems you're dealing with.
Having said that, note that we definitely do not recommend Redux-Observable as a default approach, specifically because it does add a lot of extra complication and most Redux apps don't need it - that's why we recommend thunks as the default, and Redux Toolkit includes thunks out of the box.
That's what I'm saying. Use the right tool. Before using Redux make sure you really need it.
So these are just some random statistics from some random guy on the internet. Not saying he is not right though.
Most devs still think that Redux is the only state management library and pick it just because they think so and don't want to learn new technologies. I talked to my colleagues and they simply don't want to consider using other libraries because they believe "Redux is Redux and other libraries are meh". They even didn't try those libraries. Some React devs still use class components over functional with hooks because:
Coming back to my original idea. Use the right tool and be up-to-date with modern technologies.
FWIW, I'm the primary Redux maintainer. So, sure, feel free to take my comments with a grain of salt, but A) I happen to be an expert on this topic, B) I spend most of my time answering questions about when it makes sense to use Redux, and C) I'm definitely not just "a random guy on the internet" :)
I've established a pretty solid track record of being straightforward and unbiased in my evaluations and responses:
twitter.com/tannerlinsley/status/1...
Look, I didn't want to offend you and I partially share your opinion. I'm just saying that often Redux is popular because devs don't want to consider any changes in their existing apps and don't want to try new tools in their new projects.
Recently, I have been working on a project that uses Redux but it is just about keeping fetched data. Yes, it is a lot of data but Redux is not needed for that.
Even when it is needed to store some state maybe a custom hook is enough. Tools like Recoil and Jotai (or Xstate if your choice is state machines) can keep the state and even transform it (hello Reselect).
Coming back to my point:
I think you're very right. As soon as one becomes a react developer, the very next expectation everyone seems to have of you is that you must understand and use redux. Obviously, redux isn't the only state management tool out there. There are easier and less complex tools out there. Once you get in that for most of your projects you get to use any of the options, like Recoil, useContext and so many others, its like a brush of possibilities.
To provide some additional context (no pun intended) to Vladamir's comments...
I'm sure some developers are still using Redux because they "don't want to consider any changes in their existing apps and don't want to try new tools in their new projects." Familiarity is an advantage but ought to be weighed against the benefits which alternatives would bring. Sensible developers won't only use Redux because it's familiar, but novelty should not be the only reason to switch.
I'm still someone who uses Redux because I've not yet tried a state management library which provides enough benefit to justify the switch. If I want to tell the people that I work with that we're making the switch away from Redux, I'll be talking to smart people, and they'll rightly want to know why it is that we're making this switch. Right now I don't feel like I could provide an adequately watertight answer.
For all the same reasons, if someone already knows a library like Recoil, they are right to consider why they would switch to Redux, when they know a perfectly good solution to the same problem.
Every time i work with Mobx i'm so happy about how easy and intuitive it is. Worked with Redux and Effector, but Mobx nails it for me.
"The state manager is not about being simplest, it's about being scalable and having good devtools"
I long ago realised the quest for scaleability is death to so many start ups.
You have to move fast and break things, and for god sake ship. I've seen so many good startups die to giant complexity balls bourne out of "Well what happpens when we have 20 million customers". Cool eggs, but focus on getting A customer first, because for every month your bizarely overcomplicated serverless nosql redux firebase hellmachine remains in development hell, the less enthusiastic investors become about funneling more junk money into your scheme, and then blam out of the blue someone with a simpler but functional product hits the market and eats your market becore your even laiunched. Game over.
Simplicity , is everything
I completely agree. In the highly competitive industry today, ship fast is the goal. I would bet, if we look at the source code of the early versions of those highly successful apps out there, the perfectionists among us would have a lot of negative things to say about them. But at the end of the day, those apps have beaten the hell out of over-engineered apps that just took too long to launch.
I like your point about "before even worrying about being able to serve millions of customers, focus on getting that first customer first" 😀. Although to be fair to the original comment, "scalable" in this context is probably referring to scaling with the growing feature set of the web app. But your idea still translates well to this context—"before worrying about delivering lots of features, focus on shipping out a minimum viable product first with one killer feature".