Redux / React render callback / Most.js

Let's compare Redux, plain React, and RxJS as tools for state management.

Note: Different mental models will favour different tools. See this as a starting point for further discussion, not as a final answer.


All solutions support reducers. The reducer will need the previous state and some event data (that can be of type void). It will return a new state based purely on the state- and event-data, const nextState = prevState + eventData.

Most of the logic is the same. They all (1) start with the initial state, (2) execute a reduce function based on the action type, and (3) applies the next state.

What's interesting here is that redux is instance free (think static in OOP). The React solution builds on OOP classes, and the Most variant uses factory functions.

Strengths and weaknesses

As an effect of above; Redux has serialised event types, while React and Most uses action methods bound to instances.

Redux has a state-tree and middleware support, while React has a virtual DOM-tree, and Most has state-tree and middleware that can be even more dynamic than Redux as long as you code it yourself.

Redux is a bit known for feeling heavy to develop in. RxJS (Most-alternative) is known for its high entry level threshold. React is known for being quick to get started with, except that Flux stores were tricky (pre-redux time).

Winner: React! It provides reusability, and a fast developer experience. You get minimal amount of boilerplate which can enhance readability and make on-boarding new team members much easier. There's just less code to question. The price you pay is that writing middleware will probably be more expensive than with the Most variant, and less powerful than Redux. More experimentation might change this in the future.

Most provides more power at the cost of more boilerplate to make it usable. The alternative is more extreme with a higher threshold, but matches both the Redux and pure React feature set. It's also a tool mixed with vanilla javascript. You can keep your knowledge across languages, stacks, and domains. It's the only alternative that has a chance to make it into the ECMA script standard (Observables). Learning this style will pay off more than the others in the long-run. But it's my own pattern, so I might be biased ;-)

Redux is the community's first love and forever darling. I just think that it lacks the fractal properties that makes components reusable. Many of the properties that made Redux unique are applicable without Redux-the-framework. Redux fundamentally changed the way we did state-management, and now I don't feel like I need the training-wheels from the framework to do immutable state management in React. For me, that's the biggest tribute to Redux we could give.

Appendix: Global overview vs reusability

The instance-based solutions are already prepared to be reused. That's the whole point of factories and classes! The Redux store is often seen as a global entity, and not really reusable from a fractal perspective (See: around 06:40).

Redux commonly uses global constant strings to find the right reducer. The event data is already serialised, and the data is easily logged through the system via middleware.

Middleware in React is harder since there is no single entry-point for actions, but there are hints from Ryan Florence that components are middleware (everything is a nail/component/stream).

The Most variant has a POJO component-tree that contains the actions, states, and views. It's made to be more feature complete at the cost of having more boilerplate around each part (all parts have factory functions around them). The entire application can be recursively traversed and flattened into something serialisable. You can also add middleware to subtrees since you have enough fractal properties. Note that you need to recursively travers the POJO data, and flatten the streams. Again, power at the cost of more code.

Appendix: Documentation and community

Documentation and community is a mirage. jQuery has great docs! It is not a base for a sound choice. There are great wins with small communities as well as big, so chose based on informed choices and not lines of markdown.

Personally I tend to choose the tool that needs the least amount of docs and community. (See:

Best bet is to find the perspective and background on why a tool or project exists, and what the goals are for the future. Make sure their vision fits yours. All the world's communities will still be there to help you out even if you are on the outside using a different tool. Just remember to pay it forward and help others.