[ryanbrunner]

I think there's a fair criticism of Redux in here - most well designed tools can accomodate a learning curve, and scale up the complexity when needed. I can be productive in Express without knowing about middleware, or git without knowing how to rebase.

Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a pretty big gap where you're feeling the pain of React, but Redux is still too large a complexity tax (To be fair, even to an experienced programmer it often is - for every complex state change that warrants Redux there's 50 straightforward "change this field" or "toggle this boolean" actions.)

Maybe this isn't the responsibility of Redux, and something should be built on top of it, but there needs to be some amount of consensus on what the best solution is.

[dceddia]

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.

[elliotec]

I think the answer to your question of "What drives this line of thinking" is simpler than you think:

- 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

[ryanbrunner]

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.

[acemarke]

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.

[ashark]

It's downright embarrassing to walk through a Redux-using project with someone competent who's not immersed in the JS world. Source: had to do this recently. It helps if you translate "action creator", "action", and "reducer" to terms that are less misleading in the first two cases, and less uselessly-generic in the last one, but only a little.

I tolerate it for basically "no-one got fired for buying IBM" reasons, i.e. the devs I work with think it's good and it's better to have twice as many problems and none of them be my fault than half as many and all of them be my fault.

[dceddia]

I would expand that to say, it's embarrassing/difficult to explain the JS ecosystem to experienced non-JS devs. From "why are there 132MB of packages for hello world?" to "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI".

Also, side note, it's hilarious (and maybe telling) that we both referenced the "no-one got fired for buying IBM" quote...

[tootie]

As an old-school Java dev that's been pulled into the JS world kicking and screaming, I can say that I have a pretty good appreciation for most of the complexity around modern FE builds. NPM legitimately kinda sucked up until the last few releases and is now stabilizing. I get functional programming. I even advocated for react when it was new because it felt so natural and powerful. Redux (or really react-redux) just hasn't hit that sweet spot. That being said I've seen it be hugely successful on big projects.

[com2kid]

> "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI".

Having come from cross-plat C++, the JS build system(s) are impressing me, at least the one around React Native.

One data point. :)

[ccalvert]

I perhaps foolishly go ahead and teach React and Redux to my students. The first thing I show them, however, is this article by Dan Abramov, who you perhaps know from his conference videos or his amazing work fielding React bug reports.

You might not need Redux:

https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

The little example he provides is remarkably powerful and a great intro to thinking like a Redux programmer.

[jedrek]

Abramov being one of the creators of Redux.

[acemarke]

Earlier this year, I opened up an issue to get community discussion and feedback on ways to "reduce boilerplate" and make the getting started experience easier: https://github.com/reactjs/redux/issues/2295

The discussion trailed off, but I'd love to get additional feedback and ideas on ways we can improve things and build easier-to-use abstractions on top of Redux. (Or, even better, get some volunteers to _help_ us build better tools for getting started.)

[travmatt]

Have you ever tried MobX? I haven’t tried it, but have heard it is kind of in that mid point between react state and redux

[ryanbrunner]

Yeah, personally I use it - I think it hits the sweet spot of making simple things simple while still allowing for complexity perfectly.

It's a shame I can't really teach it, however - the fact is, it doesn't have enough mindshare right now and part of the reason people take courses is to learn marketable skills. For better or for worse, nearly every React shop is looking for devs who know Redux.