MobX vs Redux: What are the differences?
What is MobX? Simple, scalable state management. MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses.
MobX and Redux belong to "State Management Library" category of the tech stack.
"It's just stupidly simple, yet so magical" is the primary reason why developers consider MobX over the competitors, whereas "State is predictable" was stated as the key factor in picking Redux.
MobX and Redux are both open source tools. Redux with 49.2K GitHub stars and 12.7K forks on GitHub appears to be more popular than MobX with 19.6K GitHub stars and 1.21K GitHub forks.
According to the StackShare community, Redux has a broader approval, being mentioned in 1021 company stacks & 803 developers stacks; compared to MobX, which is listed in 51 company stacks and 32 developer stacks.
What is MobX?
What is Redux?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Working on a project recently, wanted an easy modern frontend to work with, decoupled from our backend. To get things going quickly, decided to go with React, Redux.js, redux-saga, Bootstrap.
On the backend side, Go is a personal favourite, and wanted to minimize server overheads so went with a #serverless architecture leveraging AWS Lambda, AWS CloudFormation, Amazon DynamoDB, etc.
For IDE/tooling I tend to stick to the #JetBrains tools: WebStorm / Goland.
Obviously using Git, with GitLab private repo's for managing code/issues/etc.
I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.
By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.
Choosing redux-saga for my async Redux.js middleware, for a React application, instead of the typical redux-thunk .
Redux-saga is much easier to test than Redux-thunk - it requires no module mocking at all. Converting from redux-thunk to redux-saga is easy enough, as you are only refactoring the action creators - not your redux store or your react components. I've linked a github repo that shows the same solution with both, including Jest tests.
Frontend choice was basically pre-ordained to be React. Seems like a strong choice on merits alone, plus I needed to learn it to stay current. I never liked Redux.js from the first time I tried to work with it, but a mate had recommended MobX and after watching a few videos I felt like I could fit the mental model of hit in my head. Using Material-UI which is a great timesaver and make sure I throw a few bucks their way every month via the open source collective.
Defaulted to Rails with PostgreSQL just because that's where my past strength as a dev had been. First prototype was in Go but was struggling a bit with the quality of libraries I needed so I went back to old faithful.
As soon as TypeScript was supported by default in Create React App I ported everything over. That combined with swagger code gen has given me really good type safety from the API boundary and above. I semi-regret the Go/Rails decision because I miss the type safety despite pain points with libraries.
I will probably look to flip back to Go gradually (probably via lambda) at a point where it makes sense for the business.
After splitting our monolith into a Rails API + a React Redux.js frontend app, it became a necessity to monitor frontend errors. Our frontend application is not your typical website, and features a lot of interesting SPA mechanics that need to be followed closely (many async flows, redux-saga , etc.) in addition to regular browser incompatibility issues. Rollbar kicks in so that we can monitor every bug that happens on our frontend, and aggregate this with almost 0 work. The number of occurrences and affected browsers on each occurence helps us understand the priority and severity of bugs even when our users don't tell us about them, so we can decide whether we need to fix this bug that was encountered by 1k users in less than a few days days VERSUS telling this SINGLE user to switch browsers because he's using a very outdated version that no one else uses. Now we also use Rollbar with Rails, Sidekiq and even AWS Lambda errors since the interface is quite convenient.
Back at early 2017 the confusion and controversy around the future of AngularJS was at full swing. Also, the Angular 2 looked quite restrictive (or prescriptive even) when we did the assessment what to choose for Katana. React came out on top because it's community looked healthier, future more solid. And as you all know, one decision leads to many others: Redux, redux-saga , Axios
I use React because it is well engineered, has a huge community behind it, and allows for modular development (allowing you to handle state management yourself). I've been using React since before 1.0 (or whatever number it was they chose after 0.X). Having said this, I'm not saying other UI libraries are worse. I've barely used the other two big ones.
If using React with a non-trivial application, I heavily recommend using Redux for state management. There is no awful magic or convoluted workflow to Redux (you might not think so when starting on it, but once the light comes on, I hope you'll agree). It's all just loosely coupled state management. Remember to export your connected components separately so you can unit test the component without redux.
Though Redux makes encoding some interactions unnatural, the ease of debugging makes it worthwhile. Additionally, Redux makes it easy to implement saving/bookmarking/sharing just by serializing state
Redux's middleware is great for separating concerns, e.g., requests, errors, telemetry, etc.
Our reducers use immutability-helper to update state
We love functional approach to writing apps and Redux is thus the premium choice in this matter. The inner beauty of the state tree is unbeatable. We recently learned to solve common tasks via middleware. And the Redux Chrome extension is such a marvel - our developers request extra monitors just to have it nearby.
Our state management library of choice. Redux has a simple concept, but it's flexible enough and it's React binding library, react-redux, contains a lot of performance-optimized code to make the most out of this combo.
I have been using React/Flux since just about the beginning of React time. Redux is a great upgrade and extension of the core flux concepts, and brings immutable and strict declarative state to the apps I build.
The PrometheanTV Client Web SDK utilizes the Redux state management library to manage the state of overlay rendering during video playback.