This article was originally published on my company's blog on Medium.
In the JavaScript realm, state management has always been a topic of discussion, with multiple solutions offered by various frameworks. The reputation the topic has amassed over the years is justified by the fact that state-management is one of the hardest problems to solve in large-scale JavaScript applications.
If your application falls under the category of small to medium in size, you can get away with certain caveats, but when it comes to developing large-scale enterprise applications with strict compliance requirements, each and every choice has to be weighed down with all of its pros and cons before you can allocate development capacity and the time to develop a solution, which not only scales but satisfies all the compliance requirements.
At TickSmith, ReactJS is the framework of choice for all the standard front-end work being done for the company’s GOLD Platform. The GOLD software platform has a number of offerings such as the Data Monetization Solution that powers the world’s largest financial derivatives exchange platform for CME Group. Another offering is the Analytics Solution along with the Transaction Cost Analytics Module, which will render 100,000+ records spanning 175 metrics.
For the front-end team, building a high, throughput, low latency web client to handle enormous amounts of data was the most challenging task, which required a lot of thoughtful decisions and even careful executions of ideas. One of those decisions was to settle down for a state management library and the candidates were obvious: MobX vs Redux.
This article aims to highlight the factors and points which influenced our choice to go with MobX instead of Redux given the size and complexity of the applications we were building. They may differ depending on your use case, but the underlying challenges remain the same.
Note: We are not affiliated with either of the libraries and this article purely depicts our opinion on the subject.
Reduced Boilerplate
For anyone who has worked with Redux, it is surely a powerful state container for JavaScript applications but it comes with a cost, one aspect of that is a lot of boilerplate code. When writing code in Redux, you need to introduce four artifacts: reducers, actions, containers and components.
If you are scaling to a few hundred components in the future, all managing various aspects of the platform and orchestrating different interactions, the amount of code at one point will become unimaginable. In our use case, even by going the micro-frontend routes would bring us to the same position eventually.
As we estimated, our applications will grow dramatically in size over time and we will have to keep the codebase under control and manageable, MobX was a better option in this case. The impact of build times is not felt much in small to medium-sized applications but as your codebase grows in size, your development team definitely feels the impact of your overall experience working with the codebase, which is one of the most important factors to consider.
Multiple Stores
Redux has one large store which acts as the single source of truth whereas in MobX, you can have multiple stores. The ability to have multiple stores appealed to our development team as you can logically separate the stores based on the use case and its scope. We use different state stores for different areas in the application to segregate modules based on their scope.
Although in Redux, you have the concepts of Sub-Apps which are completely isolated and do not share data or actions, MobX makes the implementation slightly easier and more flexible in terms of managing the state of individual stores.
The Learning Curve
In my opinion, the most critical things to consider when making technical decisions around frameworks/libraries is to take into consideration the learning curve for the said technology because it heavily impacts your team’s performance and eventually your product’s time to market, which is one of the most crucial factors determining the future of your product. Going with the de-facto shiny libraries is fine but if the learning curve is too steep for your team, and you feel you will be losing valuable time choosing one library or framework over the other one, it is better to choose the one your team is most familiar with.
In our case, the teams had members with expertise in both frameworks but MobX was the winner for this point, as the learning curve around it was much lower than that of Redux. The complex nature of Redux and the hard learning curve can be discouraging for some people. It takes time to familiarize yourself and be fluent in its patterns and paradigms, as it is a mix of functional programming and flux architecture.
MobX on the other hand, proved to be easier to understand, as the library takes care of a lot of things in the background and does not strictly enforces certain paradigms, which can be both a good and bad thing.
Data Structure for State
Redux uses plain JavaScript objects as data structures to store the state. The updates to the state store are tracked manually, which can make it tricky for large scale applications. Whereas in MobX, observable data is used to store the state, which enables implicit subscriptions and allows the application to automatically track the state changes.
While these were the major influencers in our case, MobX might not be the best option for everyone depending on their use case.
The state store in MobX is mutable, which means you can overwrite the state. This can make it hard to test because your functions are not producing predictable outputs. On the other hand, the state stores in Redux are immutable. Whenever there’s a state change, it gets pushed to the state store and replaces the current state. This allows us to keep a track of state changes and even revert to the previous state if desired.
Redux is considered to be easier to scale than MobX as its functions are considered to be pure. Pure functions result in predictable outcomes, which can be easier to test. This is one of the core benefits of choosing Redux over MobX. As for our team, we follow a strict paradigm to introduce state changes within the application which is not as complex as Redux, but handles the changes very well.
Redux provides Redux Dev Tools which offers amazing support for debugging Redux code and has a developer of thousands of developers using the library. MobX does offer debugging tools. Generally, though, it is not as good in terms of functionality as compared to Redux, with a comparatively smaller community around but still large in terms of numbers.
I wouldn’t say MobX is the de-facto or a better way of doing state management in JavaScript. The answer largely remains circumstantial but given our use case and requirements, it fits the profile better than Redux which led us to make the decision to incorporate it as the default state management library.
Thanks to Guillaume Pasquet for his input.
Latest comments (0)