Why Redux is still #1?
Tags: discuss, redux, javascript
Published: 2021-09-30 10:56:40

# Intro
After a rather dull and uneventful period of Redux dominance in the UI application architecture land, there have been quite a few novel state management frameworks released over the past few years. Mobx, Recoil, Diffx, Svelte's own state management, etc. just to name a few. 

They all seem to embrace the idea of mutable state, and they seem to allow much more flexible software design than Redux. In fact, Redux as a framework forces us to use some very questionable techniques and constructs. It uses actions instead of plain methods or functions (ok it's inherited from Flux), huge switch statements to match reducers with actions, sagas to handle asynchronous side effects.  

Redux was created to tackle the problem of messy web applications with hard to reason about code, difficult to trace errors. However Redux, while it does solve those problems, it also violates almost all software design principles, results in brittle, boilerplatey, hard to maintain code. 

The biggest issue with Redux that it transforms your business domain during the implementation into something very low level, technical (for an analogy think assembly language). In other words, the resulting code does not resemble your original problem domain at all. It is a pile of reducers and sagas, with no concepts, entities, encapsulation and abstraction or in general, any structure at all. It is very difficult and costly to introduce any major or cross cutting changes into a Redux application as that requires fine adjustments and changes in many moving parts (in this code everything is open and exposed, there are no clear boundaries, or encapsulation). Yes, you can make quick initial progress and demo stuff every two weeks, at the cost of longer term maintainability. 

So if Redux has so many obvious problems, why is it still the king of state management frameworks? What stops people from migrating to lighter, more flexible and more efficient frameworks? There must be something that these newer frameworks are missing... After spending years trying to convince people about Mobx, then Svelte, I think I know the answer. Actually there are more than one reasons for this.

#Code navigability, code organisation 
If you compare a Redux based application with, say, a Mobx one, you will see that Redux has well defined locations for doing certain things, whereas Mobx is less explicit or opinionated. You can have more expectations about a Redux based project, like for instance if you look for an action fired in a component, you can be sure that there will be a reducer configured for that action, and maybe a saga as well. Even if one does not like the idea of reducers (and I for one certainly do not like it), they have to admit it does introduce a way of decoupling and and improves navigability. So I believe any successful attempts to dethrone Redux will have to offer a similar mechanism.

#Developer Tool
This is huge. People want to see how the state is changing, clearly, action after action. This is a must. Let me put it bluntly, without a Redux like developer tool, no state management framework has a serious chance to be considered as a replacement for Redux. Luckily most frameworks do offer such a tool (I can only hope that someone makes one for Svelte - Svelte has a great state offering but sadly lacks in the tooling department.) 

#One more thing...
Besides these two points, which are fairly easy to tackle (watch this space for more articles on that), there is another, more subtle issue here. 

Redux fits the present day Agile method quite well, it does not require ANY effort for an upfront design (in fact, there is no need for any design at all!). You can start "wiring in" your atomic little reducers, press a button, state changes, wonderful isn't it? Other frameworks tend to need some sort effort to map the domain to an object model, define some interactions, state transitions, etc. This does not quite play well with Agile's delivery centered approach that wants to see something moving and flashing at the first Show and Tell. 

So, my other prediction is that any successful contender to replace Redux, will have to find a middle ground, where devs are able to put something in place quickly and also to evolve a design over time, in an Agile fashion, that will help with long term maintainability and will be less sensitive to change. Exactly how that could be done is not clear to me yet, but we can clearly see the two extremes: a functional approach leading to assembly language level decomposition with all its problems, and a purely OO approach requiring heavy upfront design, often leading to difficult to reason about custom solutions. 

As usual, the ideal solution will be somewhere in the middle!