Wishes for Reactivity

Let's formulate what qualities we want to get from reactivity, and which ones, on the contrary, to avoid..

🤹‍♂️ Reasonability
🐵 Stability
🐘 Economy
💫 Consistency

🤹Reasonability

The extra computation itself gradually slows down the application. But this is half the trouble. Every extra calculation leads to other extra calculations. As a result, unnecessary calculations grow like a snowball.

Therefore, the sooner we stop them, the less resources we will spend in total. This means we’ll get a more responsive application that consumes less battery.

🐵 Stability

After changing the state, the result should be the same as starting from scratch in the same state. Otherwise, the actual behavior of the user may differ from that on which the developer is debugging.

It sounds self-evident, but you will be horrified when you find out that stability of behavior is almost never guaranteed. As a result, a situation is possible where the programmer took the same code, opened the same windows, entered the same values... but the user has a bug, and the programmer cannot reproduce it. And then the fun debugging begins.

💸 Economy

It is important to understand that all this reactivity is not free. In addition to the actual values, it is necessary to store various meta-information, the volume of which can be several times larger.

Let's take V8, for example, and see how much memory different data types require in the most optimistic case, when JIT has optimized everything as much as possible..

Value	Place	Cost
Obj	Heap	12
Array	Heap	24
Unit	Inplace	4
Int	Inplace	4
Float	Heap	12
BigInt	Heap	16+
String	Heap	12+
Ref	Inplace	4
Closure	Heap	24
Context	Heap	16

What lies in Heap eats an additional 4 bytes per link (Ref). Unit is all sorts of undefined, null, false, true and other small non-variable primitive values. Int after a billion is stored as a Float, the mantissa of which is 53 bits. Please note that this is already a reference type, like BigInt, which means it consumes an additional 4 bytes per link. The context for the closure is stored only if the function is closed to any variables. The size of the context accordingly depends on the number of these variables. As you can see (Inplace), each variable adds 4 bytes to the context.

It is easy to notice that the objects are relatively cheap. Arrays are already more expensive, because they are actually composite objects. But closures are very expensive things in themselves, even without taking into account the data stored in them.

Let me give you a few examples of calculating memory consumption..

function make_ints_state( ... state: number[] ) {
    return { get: ()=> state }
}

const state1 = make_ints_state( 777 )
// Ref + Obj + Ref + Closure + Ref + Context + Ref + Array + Int
// 4 + 12 + 4 + 24 + 4 + 16 + 4 + 24 + 4 = 96


const state2 = { state: 777 }
// Ref + Obj + Int
// 4 + 12 + 4 = 20


const state3 = 777
//Int
// 4

To summarize: depending on the selected abstractions, memory consumption can differ by an order of magnitude. And if the difference between 1 and 10 megabytes is not particularly noticeable. The difference between 100 megabytes and a gigabyte will be clearly noticeable. At best, everything will slow down. And in the worst case, the application will simply crash.

A real-life example: we open a 200-page XPath specification in Google Docs and get half a gigabyte of memory consumption.

Or another example: I was recently working on a new implementation of reactivity. And while I was flying on the plane to the conference, I meditated over this sign. As a result, I figured out how to reduce memory consumption by 2 times, turning an object with two arrays into... just one array. Of course, for this I needed inheritance, which is so unfashionable now.

💫 Consistency

And, of course, all application states must be consistent with each other at any given time.

If the user (or other software system) sees a discrepancy, even momentarily, they will be discouraged at best. At worst, both you and they will lose money, reputation and other goodies.