Hacker News new | past | comments | ask | show | jobs | submit login

Thanks for recommending Robin's other articles! I've never seen them before and they look fantastic. I was sold as soon as I saw this paragraph near the start of the Redux vs MobX article:

"Everyone wants to have state management in an application. But what problem does it solve for us? Most people start with a small application and already introduce a state management library. Everyone is speaking about it, aren’t they? But most applications don’t need ambitious state management from the beginning. It is even more dangerous, because most people are never going to experience which problems libraries like Redux or MobX solve."

One of my biggest annoyances with Javascript is that people who create new tools fail to educate potential users about the problems the tools solve, and as a consequence, a lot of developers just build these huge stacks with all the trendy tools without even knowing why they're using them. Often in the documentation for a tool there's too much focus on the 'what' and not enough on the 'why'.

The more writers harp on this point and encourage developers to learn about the tools they're using, the healthier the Javascript ecosystem will be in the long term.

To be fair Dan Abramov, who wrote Redux, repeatedly tells folks they don't need it: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Unfortunately, the general sense from the community is that it's an essential piece of the React ecosystem.

All respects to Dan Abramov, this is not necessarily true. Under the guidance of the right teacher, who knows the use cases and reasons for using redux with a React app, it can make perfect sense to learn them together. It's not easy, but most things worth it are not.

There's a reason why many experienced developers choose Redux to manage the state of their React apps. Specially once you get into async and server-side rendering, you will want or need Redux middleware such as Redux-Thunk-- or perhaps you'd like to take it a step further into observables with RxJS and Redux-Observable.

Perhaps these are all just a bunch of terms that you might not know that you need when you're first getting into React. But if you want performance and scalability -- and need an app that can withstand the pressures of today's demands -- then you may actually want to learn about all of these possibilities.

But sure -- if you're just getting into react, then by all means learn React on its own. But if you're running a large production app, I would recommend that you use redux and perhaps RxJS in conjunction with it.

Part of me thinks that Redux is going to end up being the next Java EJB - really great and important concepts at the heart, but over-adopted in scenarios which don't need it. And in a few years, there will be a backlash about it due to too much code and complexity needed to do simple things.

Dan is correct (naturally); depending on complexity and scope redux can be a drag. For a small project I will use an event emitter to communicate state change requests to my top level component. These sort of things tend to only have a handful of components anyhow.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact