Adhithi Ravichandran Software consultant, Pluralsight author, speaker, React Native/React/GraphQL dev, and Indian classical musician. You can find me online at

A definitive guide to Redux vs. MobX

5 min read 1548

One of the hardest problems to solve in large front-end applications is state management. While there are several approaches to solving state management problems, Redux and MobX are two of the most popular external libraries used to address state management in front-end applications. In this post, we will look at each library and how they match up.

This article assumes that you have a basic idea of how state management works within your web application. Both Redux and MobX are framework-agnostic and will work with any framework or plain vanilla JavaScript.


Redux is a popular state management solution that is a combination of both Flux and functional programming concepts. Some of the core principles of Redux are:

  • Redux has a single store – a single source of truth
  • The state in the store is immutable
  • Actions invoke changes to the store
  • Reducers update state


MobX is a state management solution that helps in managing the local state within your app.

Some of the core principles of MobX are:

  • MobX can have multiple stores to store the state of the application
  • Anything that can be derived from the state without any further interaction is a derivation
  • Action is any piece of code that can change the state
  • All derivations are updated automatically and atomically when the state changes

Now let’s compare some of the key features of Redux vs. MobX to see what suits your needs better.


Before beginning your quest to learn Redux or MobX, let’s look at which one is more popular.

Take a look at the Google Trends graph below. As of April 2019, Redux appears to be a much more popular and searched concept on Google in comparison to MobX.

Google Trends Mobx Vs. Redux

To get more insight into their popularity factors, let’s take a look at the State of JavaScript 2018 survey. It released data on both Redux and MobX popularity over the last three years among developers.

We made a custom demo for .
No really. Click here to check it out.


State Of JS Redux Popularity


State Of JS MobX Popularity

Over the last few years, Redux has gained a ton of popularity and has been the go-to solution for state management. Although MobX is not as popular as Redux, it has its own perks as well.

Winner: Redux

We don’t just write about Redux, we talk about it too. Listen now:

Or subscribe for later

Learning curve


The popular opinion that developers have about Redux is that it is not easy to learn. The State of JavaScript survey of 2018, analyzed the most disliked aspects of Redux. Here, developers have voted that they don’t like the complex nature of Redux and the hard learning curve that it comes with.

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.

Learning Redux also means you need to learn about Redux middleware like Thunk and Saga, which adds more material to learn.


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. It leads to writing less code since the abstraction is already built in.

Winner: MobX

Storing data — single store vs. multiple stores

The store is where we will store the local data. It holds the entire application’s state. The store typically holds the application’s state in a huge JSON object.


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. This is a more intuitive approach for many developers since they can always refer to the single store for the application’s state, and there is no possibility of duplication or confusion related to the current state of the data.


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. And the UI store would be specific to the current application.

Winner: Redux

The winner of this category is subjective; it depends on the developer’s preference. I personally like the idea of storing the entire state of the application in a single store. This helps me refer to the same place as the single source of truth. Some may argue that multiple stores work better for them and prefer MobX.

Data structure


Redux uses plain JavaScript objects as data structures to store the state. While using Redux, updates have to be tracked manually. This could be harder in applications that have a huge state that needs to be maintained.


MobX uses observable data. This helps in automatically tracking changes through implicit subscriptions. In MobX, the updates are tracked automatically, therefore making it easier for the developer.

Winner: MobX

Pure vs. impure


In Redux, the state in the store is immutable, which means all of the states are read-only. Actions in Redux can invoke changes to state, and the reducers can replace the previous state with a new state. This is one of the core principles of Redux.

A simple example of a pure function is shown below:

function sumOfNumbers(a, b) {
 return a + b;

The function will always return the same output, given the same input. It does not have any side effects or influence from the outside world.

Redux functions are written with the following pattern. Reducers are pure functions that take in a state and action and return a new state.

function(state, action) => newState

This makes Redux pure. If you are interested in learning more about pure functions and how they operate in Redux, you can read this article for a better understanding. This is one of the best features of Redux.


In MobX, the state is mutable, which means you can simply update the state with new values. This makes MobX impure. Impure functions are harder to test and maintain since they don’t always return predictable outputs.

Winner: Redux

Since the Redux store is pure, it is more predictable, and it is easy to revert state updates. In the case of MobX, if not done right, the state updates could make it harder to debug.

Boilerplate code


One of the biggest complaints about Redux is the amount of boilerplate code that comes with it. And when you integrate React with Redux, that results in even more boilerplate code. This is because Redux is explicit in nature and a lot of the capabilities have to be explicitly coded.


MobX is more implicit and does not require a lot of special tooling. It comes with much less boilerplate code in comparison to Redux. This makes MobX easier to learn and set up.

Winner: MobX

Developer community

With regards to the developer community, Redux wins hands down. Redux comes with the Redux Dev Tools that are used by thousands of developers. It offers amazing support for debugging Redux code.

MobX also offers developer tools, but they do not have the same quality of debugging support that Redux provides.

GitHub stats are a good indication of community involvement for both libraries. Redux has about 48k stars, with more than 672 contributors. MobX, on the other hand, has around 19k stars and 155 contributors.

Redux GitHub Stats

MobX GitHub Stats

If we look into the downloads from npm, Redux is way ahead. Redux averages 3m downloads a week, and MobX averages about 254k downloads a week. This shows how widely Redux has been adopted.

Redux NPM Downloads

MobX NPM Downloads

Winner: Redux


Since Redux is more opinionated and expects the reducer functions to be pure, it is easier to scale than MobX. The opinionated and pure nature of Redux enables scalability of the apps.

Pure functions are easier to test since they are predictable and simple. This results in maintainable code that can scale. This is one of the core benefits of choosing Redux over MobX.

Winner: Redux


Alright, what’s the verdict? Based on the developer community, popularity, and scalability, Redux performs better than MobX. But if you’re looking to get up to speed quickly and build simple apps with less boilerplate code, MobX might be your friend.

: Full visibility into your web apps

LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

Adhithi Ravichandran Software consultant, Pluralsight author, speaker, React Native/React/GraphQL dev, and Indian classical musician. You can find me online at

12 Replies to “A definitive guide to Redux vs. MobX”

  1. True. I would simplify this to:
    1. You learning for getting a job as a dev ASAP? Learn Redux + Saga/Thunk.
    2. Want to build something for yourself? MobX is out of competition.
    3. Just want to get started with React for hobby purposes, or just have a lot of time to learn? MobX, then Redux.

  2. Rerendering performance on state change is important category. Mobx tracks what segments of the state are used by what component and updates only those. However, there is even faster tracker for state management. Have a look into Hookstate – no boilerplate at all, incredible performance, eg. update a table with 10000 cells at the speed of 1 cell per every millisecond: (disclaimer: I am an author of the project)

  3. Agree with Andrew that a huge benefit of MobX is precise tracking of dependency trees, meaning that re-rendering is kept to the absolute minimum required for the given changes, which yields performance gains.

    When I started using Redux a few years ago, I assumed it would be “fast enough” even without dependency tracking. Fast forward to now, and I now wish I had gone with MobX. Instead, I ended up having to spend dozens of hours building a dependency tracking system on top of Redux, just to get the performance of Redux acceptable within the large and complex app I was building. (main portion here:

    It was only recently that I realized that what I’d built up, in the end, amounted to an equivalent of MobX! I then realized that, while I had improved performance, I had deviated so far from the Redux base that my system now worked closer to MobX than Redux. Because of this, I’ve decided to now transition all my half dozen live websites from Redux to MobX, so I can hook into the MobX community, and contribute what I can to it, instead of “building my own” that no one will ever know about.

    The biggest concerns I have with this upcoming change are:
    1) The MobX dev-tools are less mature than the Redux dev-tools. (main deficiency: it doesn’t have a time-travel UI built-in)
    2) I’ll have to rebuild a set of libraries on top of MobX that accomplish what the libraries I used with Redux used to do. (particularly, the library react-redux-firebase, and my extensions to it)

    The two points above I plan to resolve by building MobX versions of them myself. Unfortunately, that will take a lot of effort! But in the end, I think it’s the right choice since right now the performance of Redux is unsatisfactory. (it’s far, far better with my dependency-tracking system than without it, but it’s still not as fast as I would like) At least my efforts will then be able to benefit other MobX users as well, though, instead of just my projects.

    1. Thanks for pointing this out — we’ll try getting in touch with that blog’s editor. It looks like our post was published several months before theirs.

  4. Respectfully, your article is highly subjective and speculative. Being “pure” or “impure” does not mean a tool will scale or not scale. One can use either type of tool well or poorly.
    These days, MobX is used in many large, performant, highly transactional web apps without hitches. Also, I’ve worked for many agencies and startups and have literally *never* heard of someone being dissatisfied with MobX after using it on a real project. Most Redux developers love the the code they *don’t* have to write. They love the paradigm and wonder why they hadn’t switched earlier. That is the typical response.

    By contrast, I’ve heard many peoples’ frustration with Redux, especially in contexts where it tends to produce “overbuilt” solutions. I was interviewing a senior developer last week, and in a 2 hour coding exercise, he spent the first 1:15 just setting up all the Redux stores! This is for a simple scheduling app! What he did wasn’t “wrong” but it was too much and added complexity that had very little pay-off.

    I’ve used both, and IMV, MobX is far superior for the vast, vast majority of web apps. It’s conceptually simpler, has far less boilerplate, and “just works”. There are only a few extreme cases where Redux might be a better tool. Namely fin-tech apps that require a lot of “middleware” and cross-cutting concerns. Thankfully most of us don’t write apps like that.

  5. I don’t claim to be a Redux nor a MobX guru. But I tried to write small to medium React apps with both. MobX is a clear time winner and much, much simpler to understand and utilize. Time-to-deliver is critical for any developer and the boilerplate needed to write Redux apps simply outweighs the “assumed” benefits.

  6. Hello, Andrew! I was reading this article, and here find your project, Hookstate. I saw it and looks really great and very performant indeed. I view your Github project and the website, I have only a question, because I couldn’t find explicitly, neither in the Github readme or the website: Hookstate is only to be used in React and Preact apps, or Hookstate is framework agnostic? Can be Hookstate used with another frameworks, like Svelte, Angular, even plain Javascript? Thank you so much and please, keep your good work!!!

  7. Honestly, if someone spent 1:15 setting up redux they don’t know redux. It takes less than 5 minutes to configure a store and provider with react-redux.

    I also wouldn’t consider someone that spends that much time in an interview setting up an overbuilt solution a senior developer. Overbuilt engineering is bad engineering when it comes to software.

    I hope you didn’t hire them as a senior developer.

  8. The fact that there are people in Facebook start a new state management project called Recoil even after they are hiring Dan Abramov say it all about Redux. The concept of Redux is great, but in practice it is a pain to deal with. While is not always true, more code is generally more chance to mess up, and it’s very true to Redux. I have consulted several companies and most developers I have ever worked with never want to touch Redux again once they used Mobx.

Leave a Reply