I spent a lot of time trying to wrap my head around certain features of Redux. For example, all the currying used in various places (especially for middleware) makes it hard to follow what's going on. Indeed, the author points out in the guide on middleware tongue-in-cheek, "If your head boiled from reading the above section, imagine what it was like to write it." Part of my job is to figure things out and explain it to others. When I have a hard time understanding things myself, imagine how it's going to go for explaining it to someone else.

On the other hand, Mobx also did take a bit of time to figure out its API, but once it was clear, it was very straight forward how to use it and explaining it to others was also painless. No need for extraneous action-creators/reducers ceremony and no opinionated way of what kind of data I can use, or gotchas when that data is mutated.

Well, to be fair middleware is a rather advanced feature and most users don’t ever need to write one.

Action creators are also a mere convention and are not essential to Redux. You can dispatch action objects inline if you prefer. Reducers do add some ceremony, and I wrote up a little on the reasons here: https://news.ycombinator.com/item?id=11187727

Glad you found something you like though! No solution is perfect, and it’s all about the tradeoffs you care about.

Yes, those are fair points. It wasn't really the actions/reducers that were the biggest trouble as much as the seemingly strict design around immutable-only data. I actually think that sometimes enforcing some kind of structure around architecture helps protect it from abuse, and following a more Flux-like design seems to help more than hurt in that respect. However, it was more complicated to explain how this worked rather than Mobx's "it works like a spreadsheet" explanation.