4 ms·

I'm not sure we can quibble over the definition of a vDOM. There is the DOM as found in browsers and then there's a layer on top of that, proxying access to the

by ttfkam 4y ago

I'm not sure we can quibble over the definition of a vDOM. There is the DOM as found in browsers and then there's a layer on top of that, proxying access to the DOM, which we call a vDOM. Svelte does not have this construct. All actions are performed on the DOM without an intermediary proxy object. Tracking 100% matters, because you must iterate through the vDOM to determine the diffs that must be applied to the underlying DOM. On every change to the vDOM. This is not free. It is why the following abstraction leaks exist in React: • shouldComponentUpdate • React.PureComponent • useMemo • useCallback This is making the developer worry about things the computer should've be able to suss out for itself. You expressed concern that Svelte's compiler approach is new and therefore subject to bugs. Aside from Svelte being over 6 years old now and having gone through 3 major versions already, my assertion is that any potential bugs present in Svelte's compiler at this point pale in comparison to the number of potential (and actual) bugs or performance gaffes present in the equivalent React app due to excess lines of code, complexity, and abstraction leaks such as those listed above. The cognitive overhead is real and has a measurable effect on developer output. Bugs are proportional to number of lines of code regardless of the language being used. I assert that we developers, people, human beings, are far more fallible in this regard as to render concerns about the Svelte compiler's accuracy relatively moot. This is analogous to the switchover from Assembly to C. Early C compilers certainly had their issues, but even in the earliest days, the increase in productivity and reliability as a whole far outweighed the benefit of manually generating all instructions at that lower level. Even though today there are still optimizations to be made from analyzing hotspots and replacing generated code with assembly in those few spots, the compiler-first approach stills wins out because 90%+ of the time, it does as well or better than the hand-crafted Assembly... err... React code can in a tenth the developer time simply because compilers are now and have always been better than human beings at managing rote development tasks. Rote as in flagging variables for reactivity, (un)subscription to stores, accessing data properties, handling data binding, marking sections as immutable, etc.

horsawlarway 4y ago
Well now we can quibble! :D Svelte IS storing a representation of the expected layout of the DOM (at least the limited set it cares about). That's precisely what "reactivity" is. It's aggregating the values we've stated are important to our template (either by hand ($) or automatically (=)) and monitoring changes to those values to trigger a set of updates. The diffing happens right there. It's also why you end up with some unusual restraints on how you do assignments - if you're not careful the autodetection of "this bit was important and needs to be diffed and trigger code on changes" fails (they talk about this quite clearly, and very early: https://svelte.dev/tutorial/updating-arrays-and-objects https://svelte.dev/tutorial/updating-arrays-and-objects) I also find it bit disingenuous to call out things like "shouldComponentUpdate". That's very, very nearly the same as reactive declarations. You're having to indicate to svelte that "yes - this declaration should update". Again - it's more precise than react allows you to be, but conceptually I find it just a slightly different take on the same function. It's also why you can easily get into the same sort of cyclical dependencies that you can with react (although I think the messaging from the svelte compiler here is pretty on point, compared to react) Now - I generally find it a bit easier to suss out why the loop is happening in svelte than react (where it's not always easy or intuitive to understand that a hidden reference value may have been changed and is triggering quite a bit of downstream updates) but it's essentially the same problem space, just inverted: React makes you mark places you don't want to care about changes (useMemo, useCallback) Svelte makes you mark places you do want to care about changes ($, =) You're basically arguing that opt-in is better than opt-out, and I think that you may have a fairly compelling argument, but lets not paper over the fact that both frameworks are tackling the problem is similar ways, and both end up with their own DSLs to indicate intent with regards to changing values, and when to run code.

by ttfkam 4y ago

horsawlarway 4y ago

Well now we can quibble! :D Svelte IS storing a representation of the expected layout of the DOM (at least the limited set it cares about). That's precisely what "reactivity" is. It's aggregating the values we've stated are important to our template (either by hand ($) or automatically (=)) and monitoring changes to those values to trigger a set of updates. The diffing happens right there. It's also why you end up with some unusual restraints on how you do assignments - if you're not careful the autodetection of "this bit was important and needs to be diffed and trigger code on changes" fails (they talk about this quite clearly, and very early: https://svelte.dev/tutorial/updating-arrays-and-objects https://svelte.dev/tutorial/updating-arrays-and-objects) I also find it bit disingenuous to call out things like "shouldComponentUpdate". That's very, very nearly the same as reactive declarations. You're having to indicate to svelte that "yes - this declaration should update". Again - it's more precise than react allows you to be, but conceptually I find it just a slightly different take on the same function. It's also why you can easily get into the same sort of cyclical dependencies that you can with react (although I think the messaging from the svelte compiler here is pretty on point, compared to react) Now - I generally find it a bit easier to suss out why the loop is happening in svelte than react (where it's not always easy or intuitive to understand that a hidden reference value may have been changed and is triggering quite a bit of downstream updates) but it's essentially the same problem space, just inverted: React makes you mark places you don't want to care about changes (useMemo, useCallback) Svelte makes you mark places you do want to care about changes ($, =) You're basically arguing that opt-in is better than opt-out, and I think that you may have a fairly compelling argument, but lets not paper over the fact that both frameworks are tackling the problem is similar ways, and both end up with their own DSLs to indicate intent with regards to changing values, and when to run code.