Developing a reactivity system with Lamport clocks and incremental computation | Hacker News Reader

Developing a reactivity system with Lamport clocks and incremental computation

v5.chriskrycho.com

45 pointspcr9103039 comments

This really is brilliant in its simplicity.

Not having to maintain complex data structures to keep track of property dependencies as opposed to using light weight integer comparison to track changes. I can imagine @tracked being many times faster than @computed

It’s both faster out of the box and uses much, much less memory—which also makes it faster. As I note in the summary at the bottom of the post, because it provides no value-level caching out of the box, it does a great deal less work than the `@computed` system, and is about as cheap as it can be. But that also means you have the flexibility to layer in value-level caching when that’s the right tradeoff: something which is notoriously difficult to do (especially to do correctly) in a `@computed`-style system.

The implementation of Glimmer is really interesting, but feels like over-engineering after seeing what a compiler like Svelte can do. Here is what it would look like:

    <script>
    let maxLength = 10;
    let name = "", remaining, showError;
    $: showError = remaining < 0;
    $: remaining = maxLength - name.length;
    </script>


    <div>
      <input bind:value={name} />
      <p class:showError>{remaining}</p>
    </div>

And the gist of the runtime produced is this:

    if (dirty & 1 && input.value !== ctx[0]) set_input_value(input, ctx[0]);

    if (dirty & 2) set_data(t1, ctx[1]);

    if (dirty & 4) toggle_class(p, "showError", ctx[2]);

wired up directly to the input event which computes the dirty flags. No VM in the middle. It is quite literally impossible to get more efficient than that. Are there still any advantages to this approach?

Because that means you’re writing a different dialect of JS. Especially in the Svelte case, where you just need to be aware of what the compiler knows and what they don’t. A leaky abstraction, broken magic IMO.

BTW) I would say that writing a whole compiler to add UI update logic is much ommore over engineering than this solution, or just about any JS reactivity system.

You don't need to use the syntax sugar, a plain update function attached to the event will do fine, just more verbose. It's in fact _less_ magic when the output JS is perfectly readable, and doesn't require unravelling thousands of lines of runtime libraries.

I'm surprised you'd think of that as a leaky abstraction, but not a `@tracked` decorator. They are both 'different dialects of JS', and both use a compiler.

To be clear, the decorator only involves a compiler because the spec isn’t finished. When it is, it’ll just be normal runtime JS with no need for a compiler. There is a compiler invoked at the template layer, but nothing requires that for the rest of this system to work. Autotracking is a general-purpose reactivity system and it does not require any compilation in a formal sense; Svelt does. None of that is a criticism of Svelte, which I very much like and admire. But the difference is worth understanding clearly!

In terms of the tradeoffs here, I haven’t dug deeply enough into Svelte to have a reasonable opinion beyond the first blush “I really like this!” The way it uses compilation and repurposes unused JS features to build a reactivity DSL is very clever and interesting and the compilation output is smart and well-optimized, even if I find the use of exports to be a bit quirky.

I found this super interesting and read around on the glimmer website. The comparison to React at the bottom of this page was especially helpful.

https://glimmerjs.com/guides/tracked-properties

This looks exactly like MobX

There are definitely similarities! A key difference is that you can actually implement MobX in terms of autotracking. Autotracking is a lower-level primitive that you can use for all sorts of higher-level systems.

Reply on news.ycombinator.com