I switched to MobX and can't be happier. Performance is never a problem and everything is just simpler and easier to understand. I think you should give MobX a shot.
> mobx-state-tree is a state container that combines the simplicity and ease of mutable data with the traceability of immutable data and the reactiveness and performance of observable data.
Preethi Kasireddy did a fantastic presentation at ReactConf comparing Redux and MobX [0], Robin Wieruch wrote a good article comparing them last year [1], there was a Reddit thread with good discussion as well [2], and I have links to more comparisons at [3].
They're different tools taking very different approaches to solving the same kinds of problems, and they definitely appeal to different developers.
Yup. Redux also fits better people who like more vanilla code at the expense of verbosity. MobX fits better people to prefer terseness.
Redux falls apart pretty hard when people start layering sugar and abstractions on top. It's my pattern of choice, but for teams that insist on abstracting the Redux boilerplate away, I steer them to MobX.
Yep. Redux does a great job of pushing mutation out of your application logic and into the library machinery, much like React does. Together, you get logic that's remarkably pure. It makes for an application that's dead simple to debug.
I've never tried MobX, but it looks pretty impressive too. I can imagine it working really well if you have the discipline to not leak your mutations all over the place.
MobX (in strict mode) forces you to annotate your mutations (via the @action decorator).
MobX is useful mostly as the data model / selector part of redux. It does an awesome job of it. Once you've defined your core data model, you can create layers of computed properties and transformations out to your view. The view then rerenders in a really optimal way.
Where redux shines is the prescriptive nature. The layout of a redux app is fairly well defined at this stage and there are "right" and "wrong" places to put (and look for) different types of code.
With MobX there's still no clear way to layout your application, so, as you say, you need to be more disciplined with your approach.
I've found the opposite. Coming from FP like Clojure, Redux just feels unwieldy in comparison, whereas MobX feels like it fits the language/problem better (but has plenty of it's own issues)
Same thoughts here about MobX. I tried my best to like Redux from my early on React days but could never get myself to like it, Mobx on the other hand has been a way more pleasurable and productive experience. I don't know or understand much about the pros and cons around Immutability and FP paradigm of Redux, but I sure can ship my apps faster and quicker using Mobx - which for a small bootstrapped startup like mine could mean the difference between life and death.
After having used Mobx for more than 10 months now, I still have to find areas that I dislike about Mobx.
As others have said, it does allow you to get much messier with your code than the rigid structure of Redux so you have to be more careful with your structure. My first MobX app was (and in some ways still is) a bit of a mess in spots.
That said, my subsequent apps have gone much better and I definitely prefer it to Redux, but I can see the appeal of Redux's more structured approach.
