Developing a reactivity system with Lamport clocks and incremental computation

Re:Developing a reactivity system with Lamport clocks and in... by ricardobeat on Monday September 28, 2020 @05:18AM (#24614643)

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.

[ Parent | on HN ]

Re:Developing a reactivity system with Lamport clocks and in... by chriskrycho on Friday October 02, 2020 @11:55PM (#24669392)

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.

[ Parent | on HN ]