The Redux learning curve is tough, especially for folks who don't already have a strong grasp of functional programming ideas. Immutability is weird. Breaking everything up into multiple places (dispatch, actions, reducers) is weird. Like you say, it's unfortunate that one must basically learn _all of it_ to get started using Redux. It does do a nice job of solving difficult problems though.
> there needs to be some amount of consensus on what the best solution is.
The thing is, there is consensus: it's Redux. I'm not saying that's good or bad, but it's king of the state management hill right now.
What's really interesting to me is that the JS community is largely allergic to anything that isn't the "best solution". Nobody wants to use a little library with 53 stars on Github, even if it's easier, or seems like a better fit than Redux. The thinking seems to be "It's not any good unless it's the most popular choice." Those sorts of libraries might be ok for proof-of-concept work, but not for the real world. Not for production.
What drives this line of thinking? I think it's complex, but I believe fear plays a big role.
- Fear of choosing the wrong library (what if it becomes unpopular!)
- Fear in one's own abilities to evaluate a library ("it seems fine to me, but I'm no authority, I can't make that call")
- Fear of looking bad to the boss ("Nobody ever got fired for buying IBM", right? React + Redux has that spot right now)
There's also the self-reinforcing nature of a popular thing: companies using Redux => job listings require Redux => people want to learn Redux => people make Redux courses/books/blogs => people don't teach the alternatives.
There's consensus on Redux - that's not what I'm talking about. There seems to be a fair amount of desire for something that simplifies "straightforward" state management. The Redux maintainers don't seem to be interested in this, preferring it to be something created by the community. As far as I can see though, no one is filling that gap.
I'm a Redux maintainer, and I'm _absolutely_ interested in making it easier for people to get started with Redux. I opened up an issue thread earlier this year to get community feedback and ideas on how we can do that: https://github.com/reactjs/redux/issues/2295 .
We don't plan to modify the Redux core itself, but I would _love_ to be able to list some tools as "approved" or "blessed" ways to get started easier.
Sadly, I just don't have enough free time to go build much of anything like that myself, but I will happily work with anyone in the community who's interested in doing so.
I also hope to revamp the Redux docs "Ecosystem" page to more specifically point to certain tools as recommended solutions to specific problems, but again haven't had time to do so yet.
> there needs to be some amount of consensus on what the best solution is.
The thing is, there is consensus: it's Redux. I'm not saying that's good or bad, but it's king of the state management hill right now.
What's really interesting to me is that the JS community is largely allergic to anything that isn't the "best solution". Nobody wants to use a little library with 53 stars on Github, even if it's easier, or seems like a better fit than Redux. The thinking seems to be "It's not any good unless it's the most popular choice." Those sorts of libraries might be ok for proof-of-concept work, but not for the real world. Not for production.
What drives this line of thinking? I think it's complex, but I believe fear plays a big role.
- Fear of choosing the wrong library (what if it becomes unpopular!)
- Fear in one's own abilities to evaluate a library ("it seems fine to me, but I'm no authority, I can't make that call")
- Fear of looking bad to the boss ("Nobody ever got fired for buying IBM", right? React + Redux has that spot right now)
There's also the self-reinforcing nature of a popular thing: companies using Redux => job listings require Redux => people want to learn Redux => people make Redux courses/books/blogs => people don't teach the alternatives.