Redux vs Mobx have been the hot topic in the development world ever since their arrival. Both of them are compared with each other very strictly for every single discussion. Because of this, it becomes very difficult for people to choose which one is the best for them. Whenever there exists an alternative, people are curious what's the best way to solve their problem. To help you with that, we have made a comparison of how they are different from one another and what should be the go-to option for you.
Redux or MobX for Newcomers?
Once you are familiar with React components and internal state management, you can choose a state management library to solve your problem. After I used both libraries, I would say MobX can be very suitable for beginners. We could already see that MobX needs less code, even though it uses some magic annotations we may not need to know about yet.
In MobX you don't need to be familiar with functional programming. Terms like immutability might be still foreign. Functional programming is a rising paradigm, but novel for most people in JavaScript. There is a clear trend towards it, but since not everyone has a functional programming background, it might be easier for people with an object-oriented background to adopt the principles of MobX.
Learning curve
The popular opinion that developers have about Redux is that it is not easy to learn. It takes some time to understand its patterns and paradigms. It is a combination of the Flux architecture and functional programming concepts. If you are a functional programmer, you may find it easier to grasp Redux, whereas if you come from an object-oriented programming background, Redux code initially looks complex and hard to understand.
MobX is known to be much easier to grasp when compared to Redux. Most JavaScript developers are well versed in object-oriented programming, which makes learning MobX simple. Also, there are a lot of things that are done behind the scenes in MobX, creating a better learning experience for the developers. You wouldn’t need to worry about normalizing the state or implementing concepts like Thunks.
Data Storage
In Redux, there is only one store, and it is the single source of truth. The state in the store is immutable, which makes it easier for us to know where to find the data/state. In Redux, although there is one giant JSON object that represents the store, you can always split the code into multiple reducers. This way, you can logically separate the concerns with multiple reducers.
MobX, on the other hand, allows multiple stores. You can logically separate stores, so all of the application’s state is not in one store. Most applications are designed to have at least two stores: one for the UI state and one or more for the domain state. The advantage of separating the stores this way is that you can reuse the domain in other applications as well.
Top comments (2)
I’ve never really messed with MobX, but I enjoy Redux, even coming from a generally OO background. I needed to learn it for a Preact project at work, and it took about 2-3 weeks to get the hang of it. Learning to use Redux in its simplest form, without react-redux, really helped.
I found managing Redux overtime for a large application can become difficult. Haven't done much with MobX, but could see it being useful in having some separations of concerns via stores. As managing namespaces in redux can again become cumbersome overtime especially as developers are constantly adding/building new features.
Would like to point out though when using React, I don't use any of these libraries anymore and rely on react-hooks. And I'd encourage folks that are doing/learning React to adopt hooks as well. But to @andyrosenberg point, if you are using a non-react javascript interface I could see these frameworks/libraries still being useful.