| 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. |
- More popular libraries are better maintained and have more support
- More people use them (obviously), so more problems will already have already been solved the ${library} way
- Much easier to hire developers who know the more popular libraries