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