Reactivity Practicality in Popular JS Libraries

#webdev #javascript #architecture #reactivity

Let's now take what we know about reactivity and try to formulate what the most practical model of reactivity might look like. What properties should it have to make it pleasant to use, so that it gives us a minimum of problems, so that the user has everything stable, fast, and always understands what is going on..

Aspect	✅Usable	❌Unusable
Style	🤓Obj	🧐Proc 🤯Func 😵Cell
Watch	🤝Links	🔎Polling 🎇Events
Dupes	🎭Equality	🆔Identity 👯‍♀️Every 🔀Reconcile
Origin	🚂Pull	🥌Push
Order	👨‍💻Code	📰Subscribe 🧨Event 📶Deep
Flow	🚕Auto	🦽Manual
Tonus	🦥Lazy	🍔Instant ⏰Defer
Error	🦺Store	⛔Stop ⏮Revert 🎲Unstable
Cycle	🌋Fail	💤Infinite 🎰Limbo 🚫Unreal
Depth	🌌Heap	🗻Stack 🚧Limit
Atomic	🦶Base	🤼‍♂️Full 👻Alone
Extern	🏇Async	🏊‍♂️Sync

Let's now take various well-known libraries and frameworks and see how close they are to the ideal... But first, a small note...

Default behavior

Below we consider only the default behavior and the code style recommended by the authors. It is clear that you can always somehow get around the problems. Somewhere the behavior can be changed with a config parameter. Somewhere you need to remember to write additional code here and there. Somewhere you need to get creative with hellish crutches. And in some cases you will have to abandon one library altogether and add another one on the side.

However, it is important to understand that the author of the library, even if he is deeply wrong, most likely has greater expertise than an ordinary application developer. In this topic in general, and in his library in particular. Therefore, most third-party code using it will be written in the canonical style, designed for default behavior. And any departure from the default will require additional code, which you must remember to write, and spend time writing it correctly.

🎓 Expert's choice
🐭 Minimum code
👀 Increased attention
👾 Third party code

Further comparison is useful not so much in order to understand which one should be taken urgently and which one should be thrown away immediately. But also in order to understand what you need to be prepared for when starting a project on a particular technology.

Some aspects may be completely unimportant to you. Some may turn out to be show stoppers. And some can be easily bypassed. And it would be nice to lay some straws in advance so as not to have to deal with painful debugging and optimization later.

Reactive libraries

Lib	Style	Watch	Dupes	Origin	Tonus	Order	Flow	Error	Cycle	Depth	Atomic	Extern
$mol_wire	🤓 ✅	🤝 ✅	🎭 ✅	🚂 ✅	🦥 ✅	👨‍💻 ✅	🚕 ✅	🦺 ✅	🌋 ✅	🗻 ❌	👻 ❌	🏇 ✅
CellX	🤓 ✅	🤝 ✅	🆔 ❌	🚂 ✅	🦥 ✅	👨‍💻 ✅	🚕 ✅	🦺 ✅	🌋 ✅	🗻 ❌	🦶 ✅	🏇 ✅
MobX	🤓 ✅	🤝 ✅	🆔 ❌	🚂 ✅	🦥 ✅	👨‍💻 ✅	🚕 ✅	🦺 ✅	🌋 ✅	🗻 ❌	👻 ❌	🏊‍♂️ ❌
ChronoGraph	🧐 ❌	🤝 ✅	🆔 ❌	🚂 ✅	⏰ ❌	👨‍💻 ✅	🚕 ✅	⏮ ❌	🌋 ✅	🌌 ✅	🤼‍♂️ ❌	🏊‍♂️ ❌
Reatom	🤯 ❌	🤝 ✅	🆔 ❌	🚂 ✅	🦥 ✅	🧨 ❌	🦽 ❌	⏮ ❌	🚫 ❌	🗻 ❌	🤼‍♂️ ❌	🏊‍♂️ ❌
Effector	🤯 ❌	🤝 ✅	🆔 ❌	🥌 ❌	🍔 ❌	📰 ❌	🦽 ❌	🎲 ❌	💤 ❌	🌌 ✅	👻 ❌	🏊‍♂️ ❌
RxJS	🤯 ❌	🤝 ✅	👯‍♀️ ❌	🥌 ❌	🍔 ❌	📰 ❌	🦽 ❌	⛔ ❌	🚫 ❌	🗻 ❌	👻 ❌	🏊‍♂️ ❌

There are two main camps here: “Imperative Reactive Programming” and “Functional Reactive Programming”. As you can see, the currently fashionable functional approach is not very practical, unlike the more old-school imperative approach.

It’s also worth noting that RxJS itself is not about reactivity. It is fundamentally about controlling the flow of execution. However, with its help it is possible to describe invariants connecting states, and then we get a reactive system.

Many thanks to the library authors for their help in preparing this table. Write to me if you want to add yours to the comparison. I will try to keep this sign up to date, if the community, of course, helps me keep track of all the news.

$mol_wire

The leader, of course, turned out to be $mol_wire, which I implemented after this analysis. There is a detailed article about why it is good and why it works the way it does, which I highly recommend reading, because at the end there will be some pleasant surprises waiting for you..

Designing an ideal reactivity system

Its predecessor $mol_atom2 had all the same qualities, so in the $mol framework we quite quickly completely moved to the new implementation of reactivity. And by the way, about frameworks...

Reactive frameworks

Lib	Style	Watch	Dupes	Origin	Tonus	Order	Flow	Error	Cycle	Depth	Atomic	Extern
Vue	😵 ❌	🤝 ✅	🆔 ❌	🚂 ✅	🦥 ✅	👨‍💻 ✅	🚕 ✅	🦺 ✅	🎰 ❌	🗻 ❌	👻 ❌	🏊‍♂️ ❌
Ember	🤓 ✅	🔎 ❌	🆔 ❌	🚂 ✅	🦥 ✅	👨‍💻 ✅	🚕 ✅	🎲 ❌	🌋 ✅	🚧 ❌	👻 ❌	🏊‍♂️ ❌
Solid	🧐 ❌	🤝 ✅	🆔 ❌	🚂 ✅	🍔 ❌	👨‍💻 ✅	🚕 ✅	⛔ ❌	🚫 ❌	🗻 ❌	👻 ❌	🏊‍♂️ ❌
React	🧐 ❌	🔎 ❌	👯‍♀️ ❌	🥌 ❌	⏰ ❌	👨‍💻 ✅	🦽 ❌	⛔ ❌	🌋 ✅	🚧 ❌	👻 ❌	🏇 ✅
Angular	🧐 ❌	🔎 ❌	🆔 ❌	🥌 ❌	⏰ ❌	👨‍💻 ✅	🚕 ✅	🎲 ❌	🎰 ❌	🚧 ❌	👻 ❌	🏊‍♂️ ❌
Svelte	🧐 ❌	🔎 ❌	🆔 ❌	🥌 ❌	⏰ ❌	👨‍💻 ✅	🚕 ✅	⛔ ❌	🚫 ❌	🌌 ✅	👻 ❌	🏊‍♂️ ❌

Analysis of frameworks in terms of reactivity is somewhat arbitrary. It usually manifests itself in two aspects: invariants between the states of one component, and the connection between the state of one component and the parameters of another.

As you can see, proceduralism is more popular here, which is also not the most practical approach. And the most practical thing here is Vue. Only $mol is cooler than it, but there is no point in considering it separately as a framework, because it simply uses the $mol_wire library as a circulatory system, and we have already analyzed it earlier.

It is important to note that you should not blindly trust these plates, because they are compiled manually. I, of course, tried to reflect everything as accurately as possible, but I could have messed up somewhere. That's why..

More about Reactivity

state-management-specification / Artyom Arutyunyan
What Makes a Good Reactive System? / Chris Garrett
A General Theory of Reactivity / Kris Kowal
A Hands-on Introduction to Fine-Grained Reactivity / Ryan Carniato
Object Reactive Programming / Me @ FrontendConf'17
Quantum Mechanics of Calculations in JS / Me @ HolyJS'18

Artyom (author of Reatom) has an interesting project to classify state managers using tests. This is a slightly broader topic, since, for example, Redux is a state manager, but it is not reactive. This is just a transactional change in the state tree and that’s it, no cascading invariants between states. If you are interested in this topic, then get involved in writing tests - it will be useful for the entire community.

In a series of articles from Chris Garrett, you can see how the reactive model was rethought in the Ember framework. I have left a link to the most relevant one.

An in-depth article by Kris Kowal looks at the issue of reactivity from a different perspective. In my opinion, he is wrong, but you can read it to broaden your horizons. But the one I agree with is the author of SolidJS - Ryan Carniato, who talks about how to make a practical reactive system.

Finally: a couple of my speeches examining the advantages of ORP and the mechanics of implementing asynchronous invariants will help to delve even deeper into the topic.

More from Me

For 10 years now I have been actively sharing knowledge, ideas, and open source. And each of my materials is an original, and sometimes radical, idea, tested in practice. So it's worth checking out all of this, even if you don't plan to use it.

jin.hyoo.ru - my own articles, performances and other
mol.hyoo.ru - knowledge base related to $mol
Core Dump - my fundamental speeches
_jin_nin_ - my development news on X
h_y_o_o - HyperDev community in Telegram

Contribution

This is the fifth year that I have stopped working, but am engaged in computer science and open-source projects. So if you find my work useful, you can thank me by donating or even patronizing me..

tinkoff.ru/cf/1VnW7ZtTeg2 - one-time payment
boosty.to/hyoo - subscription
idea.hyoo.ru/#!person=4ynowz_qskrm7 - our open source projects

So, you can help simply by sharing a link to my articles with your friends. I don't have a very large media resource, although my articles could be useful to many developers.

We, in the HyperDev Guild, have many interesting projects that should soon change the world. So the most valuable contribution you can make is not even money, but participation in projects.

We want to create an ecosystem of tightly integrated web services using the most advanced and cheap technologies. And to displace the open source of the current Internet giants. Join our little revolution!