The Cost of Consistency in UI Frameworks

So honestly, this all sucks.

Really?

I'm pretty sure all four are internally consistent.

When it comes to solution approaches there is no universal model to consistency ("All models are wrong, but some are useful", remember).

What is important is that once you are equipped with the mental model that is appropriate for the framework/library that everything is predictable.

The Principle of Least Astonishment (POLA) isn't an unassailable law; it fails to acknowledge that an individual's level of surprise is directly correlated to their past individual experience. So what level of "majority experience" is required for POLA to be valid?

JavaScript is most despised because it isn’t some other language. If you are good in some other language and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying. Most people in that situation don’t even bother to learn JavaScript first, and then they are surprised when JavaScript turns out to have significant differences from the some other language they would rather be using, and that those differences matter.

[Douglas Crockford, JavaScript - The Good Parts, 2008; p.2]

For decades JavaScript has aggravated developers worldwide because it didn't meet the expectations set by their first or favourite language. That didn't stop JavaScript from "eating the world". If JavaScript surprises you then your "mental model of JS" is faulty.

Similarly when switching between frameworks/libraries it should be expected that adjustments to one's mental models have to be made. (OK, that part sucks but that's the cost of doing business.) Ideally any tool should adopt the internal consistency model that allows it to operate the most efficiently and effectively as an end product (i.e. "in production").

That said every effort should be made in the documentation for that tool to lay bare the optimal mental model so that developers don't have to waste time "being surprised" during the on boarding process.

I would call Vue's lazy computation approach "invisible inconsistency". What's inside doesn't really matter, as long as everything looks consistent to the outside observer.

When you access the reactive properties programmatically, the desired part of the subgraph is updated on the fly.

Yes, if you access the DOM directly, you get inconsistency in Vue. But that's a Vue-specific problem that Vue can easily solve. For example, in $mol_view, each component has two methods: dom_node that returns the current DOM element as is, and dom_tree that returns the same DOM element, but ensures all its subtree is up to date.

@mem count( next = 0 ) { return next }

@mem doubleCount() { return this.count() * 2 }

@act test() {

    this.count( this.count() + 1 )

    console.log( this.count() ) // 1
    console.log( this.doubleCount() ) // 2
    console.log( this.dom_node().textContent ) // "0"
    console.log( this.dom_tree().textContent ) // "2"

}

The user will not see an inconsistent state either, because the whole reactive state tree will already be updated automatically by the time it is rendered. In $mol_wire, we go one step further and don't do the full update at the end of the current event handler, but postpone it until the next animation frame. Thus recalculations caused by different events for a short time (about 16ms), when the user will not see their result, are not performed unnecessarily.

The Solid model has exactly the opposite approach, resulting in low default performance, and consequently the need for additional gestures for optimization. But the worst thing is not even that, but that exceptional situations at least break consistency, and at most break the application (although the second seems to be just a critical bug):

const [count, setCount] = createSignal(0)
const doubleCount = createMemo( ()=> count()%2 ? aBug() : count()*2 )
const increment = () => setCount(count() + 1)

console.log( count(), doubleCount() ) // 0 0 OK

try { increment() } catch {}
console.log( count(), doubleCount() ) // 1 0 Inconsistent, exception expected

increment() 
console.log( count(), doubleCount() ) // 2 4 OK

// After 100 clicks outputs: 4
return (
  <button type="button" onClick={increment}>
    {doubleCount()}
  </button>
)

I think you are comparing pears to oranges or apples here ... the Solid code does something obvious the react one cannot literally do.

// oh look, count() is a function invoke, not a constant
count() === 0; // true

// oh look, setCount(value) updates next count() invoke because
// ... that's NOT a constant ...
setCount(count() + 1);

// oh look, 2 functions invokes + a side effect happened
// synchronously hence BLOCKING the main thread
console.log(count(), doubleCount(), el.textContent); // 1, 2, 2

And uland would do the same React does, without needing any tooling around, but that's absolutely expected.

This whole thread looks to me like this question:

Do you understand that const [value, updateValue] = useState(initialValue) makes both value and updateValue constants, not callbacks that can side-effect or have a different returned value each time, like any callback could in general, as programming rule?

As summary, I am not sure this post was super needed, fair, or relevant, as much as I appreciate all the work done behind Solid.js.

P.S. shall we talk about that blocking thread Solid.js behavior instead?

edit if anything, I think this is the only inconsistency React (and uhooks in uland) might need to solve:

setCount(count => count + 1);
setCount(count => count + 1); // results in 2 eventually

Within the same execution stack calling setCount(count + 1) multiple times will result into having count + 1 live as next state, but using a callback might indeed produce shenanigans because the previous count might have been already updated ... however, to be honest, I've never seen a useState update function used more than once or in multiple places and within a callback ... but fair enough, this is a consistency bug, imho, not a feature, if that's the result.

Svelte can have consistency similar to Solid's, when (and where) you need it:

import { tick } from 'svelte'

let count = 0;

count++;
await tick()

console.log(count, doubleCount, el.textContent); // 1, 2, 2

This is a bit late, but I'm a bit surprised to not see the words "database" or "transaction" appear in a discussion about state consistency / reactivity. One could imagine implementing reactive components basically as SQL-style (materialized) views, and implementing state management with SQL-like transactions -- e.g. with ACID-style guarantees. I'm not the first person to think of implementing UIs in this way, see for example

cs.columbia.edu/~ewu/files/papers/...

I'm not a web developer, so I apologize if this is all old news!

Is console.log the right metric to compare these frameworks with though?

The user doesn't see it, and it isn't shown in the UI, so is the entire concept of "which changes first" or "inconsistencies" lean more toward when side-effects (like printing to the console) occur rather than consistency in the UI?

This might be a bit too much of a "creating a problem to satisfy a solution" situation.

I have converted a react app (desktop like ui with apps and folders) with heavy use of drag and drop to Svelte and I ended up with corrupted wrong state everywhere, so I stayed with react. No idea if its just me or really its related to something mentioned here but the way state behaves in complex situations in Svelte just feels unsafe.

I would point out that a lot of the surprise comes down to the semantics of the function names.

I too have seen bugs come from failure to understand that React's changes are scheduled later. I submit that the reason React's result is so surprising for many devs is that the name setCount (and it being widely documented by React and others as a setter function) strongly suggest that it will, you know, set the value of count and do it now — not after this render call returns, not a few milliseconds after that, but immediately. Otherwise how can the code have a predictable execution context? And if it doesn't set count now, then why is it referred to as a setter function, named setCount? The naming semantics are bad.

Svelte similarly fails on semantics and perhaps false promises. It sets count immediately, but then doubleCount — which is supposedly is derived from count — is not recomputed immediately and is therefore inconsistent its own name — doubleCount is no longer double the value of count.

Variable and function names are important for understanding code and communication design contracts. Any time a function or variable doesn't have the behavior or value indicated by its name is a sure sign that something is amiss, and bugs are likely to follow.

So I would say that of the above approaches, Solid is doing it right. Yes, that may sometimes involve some redundant calculations and a little less efficiency. But if the second function returned by createSignal is going be called a setter function — with a convention of being named setSomething — then it better damn well set that something immediately, each and every time that it is called. There's too many decades of precedent in this matter for a setter function to do anything else.

Wanna have a batch mode for maximal efficiency? Fine, but make it a new variant of signal — e.g. createDeferredSignal — and change the docs for that to suggest that the second function returned by it should be called updateSomething to indicate that such updates will not be immediate. Then it should be sufficiently clear that recompilation of any memos derived from that deferred signal will not be immediate either.

Imo the most expected flow is the one solidjs has. U write a sync code -- expect sync results. But considering the harsh reality of the slow dom and the fact that model-first concept is most comfy one, one can sacrifice the dom update consistency (as no one really cares about what dom displays at all, data-only remember) and then vue's approach seems the most predictable data-first, dom performance-oriented.

I'm proposing an alternative: what if you just ban eager read

Pawel Kozlowski

@pkozlowski_os

I can see 3 options to solve "accessing reactive primitives in a non-reactive context":
- make "everything" reactive context (React);
- make reactive boundaries explicit (ex. createEffect in Solid, $: in Svelte);
- disallow reads of reactive atoms outside of the reactive context. twitter.com/sebmarkbage/st…

13:09 PM - 21 Jun 2022

Sebastian Markbåge @sebmarkbage

@lxsmnsyc @RyanCarniato @flaviocopes @srsholmes @wesbos @sveltejs Yea and Svelte is the same, especially when using equivalents to Hooks. Which is fine, but in my mind you shouldn’t have access to props in those code paths. Except as input to “initial state”. It’s too easy to use the initial stale props. Otherwise I love the simplicity of it.

3Shain

@san3shain

@pkozlowski_os The 3rd option makes the most sense IMO. It's the only one I found which is very likely to get along with concurrency, I mean, "perfectly".

08:00 AM - 22 Jun 2022