Some feedback

[einarq]

Interesting comparison :) Wanted to weigh in a bit.

A couple of comments first:

• The links at the bottom of the Readme both link to the MobX version
• It has always been recommended to co-locate selectors with the reducers (since only selectors and reducers should know the shape of the store), so that extra file seems a bit contrived

Other than that I would say that it is important to understand the motivations behind the different libraries. Redux is extremely useful (speaking from experience) when developing a large and complex applications where you want to trace all actions and updates to the state. This is now even better with the new and improved Redux dev-tools which let you trace where an action is being triggered from.
Due to the benefit this gives I don't mind the extra files personally. Also, it's not really something you do that often in my experience (dealing with the different files). Personally I try to limit the amount of actions (in particular avoiding "setter" actions and also keep in mind that several reducers can respond to the same action), so I spend more time in my React components building the actual app.

MobX is meant to be more "simple" I guess, while still being fast. Personally I avoid things that seem a bit too magical, MobX just reminds me a too much of Knockout, Angular, and Backbone+Stickit, which seemed great at first, but which gets frustrating as the app grows and you start to lose control.
Also worth noting that Sebastian Markbage has stated that, while MobX is probably great, it is not very much in line with the future of React (https://twitter.com/sebmarkbage/status/1032684851063705600).

So for a larger app that might grow more complex over time, Redux is atm a good choice imo. I know a lot of people are very happy with MobX as well, but I would be worried about long-term maintainability for larger projects, as well as compatibility with future versions of React.

For a simpler app I would probably just use basic setState in combination with the new Context API (which does not replace Redux...), or perhaps look into something like Unstated.

Hooks should also make it simpler to roll your own state management for smaller apps in the future.

This article gives a very good explanation, and the final thoughts are pretty much spot on in terms of how I feel about this personally:
https://www.robinwieruch.de/redux-mobx-confusion/#finalThoughts

Regards,

Einar

[xinsight]

Hi! Thanks for your comments. I fixed the readme links.

You're right, you could put all the redux actions, action creators, reducers and selectors in a single file since they are all just a bunch of "loose" variables. Some people find that breaking things into files provides some order - and prevents you from having to scroll in a massive file. But those things really do belong together, so having every branch of the state tree in a single file would make life easier. My criticism against redux isn't so much the number of files, but the lack of structure, and the onus on the developer to try to keep all these variables and concepts organized.

Redux is extremely useful (speaking from experience) when developing a large and complex applications where you want to trace all actions and updates to the state.

This is often mentioned as the great benefit to redux – that the extra effort required will payoff as your application grows. However, I don't see how this is true. If simple things (like the app in the shootout) are verbose and somewhat complicated, how will that help when trying to build more complicated things?

In my experience, adding a variable to a redux store (e.g. tracking the state of a toggle control) requires an action, an action creator, a reducer, a selector, and then separate methods to wire up the setter (mapDispatchToProps) and the getter (mapStateToProps). In comparision, adding a variable to a MobX store is a one-liner, injecting your store into a component is another one-liner, and accessing the variable (for setting or getting) is another one-liner.

but I would be worried about long-term maintainability for larger projects, as well as compatibility with future versions of React.

That seems like just FUD to me. Why would shorter, simpler, more readable code be harder to maintain? MobX is not magic. It tracks which components access variables in the store, and then if the value in the store changes, it triggers a render on those components that accessed the variable. It's a powerful concept - and I'm still finding amazing new things you can do with MobX.

For example, reactions allow you to run any arbitrary code when when a store value changes. So, let's say that after a login, the server returns a userId, and then you need to hit a different endpoint to pull more info about the user. In your store, if your userId is observable, you can add a reaction to fire off code whenever the userId changes. Simple. With redux, you'd have to listen to the SET_USERID action, and create/dispatch another FETCH_USER_PROFILE action, which would be used to trigger a saga/thunk. It's more verbose and "spread out". (And you had better hope that you never want to rename your actions, because refactoring the action constant, action creator, reducers, etc. is painful chore.)

Hooks should also make it simpler to roll your own state management

Maybe, but I'm skeptical. React wants everything to be a component (e.g. higher-order components, container components), but keeping the data model out of components seems cleaner to me. But I'm always interested in ways to write simpler, more elegant code.