4 ms·
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
by pcr910303 6y ago
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.
- ricardobeat 6y agoYou 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.
- chriskrycho 6y agoTo 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.