6 ms·

I'm not the writer of the post, but what I understand is that Svelte is a super-leaky abstraction mostly because the compiler's output is unpredictable. JSX (t

I'm not the writer of the post, but what I understand is that Svelte is a super-leaky abstraction mostly because the compiler's output is unpredictable. JSX (that most React-esque libraries use) is basically a syntactic sugar for function calls with objects - so the output is fully predictable. One of Svelte's selling points was that it abstracts complex state management by compiling JS down into DOM API calls - but that abstraction is leaky and it's hard to debug why something's not working when it's expected to be.

rimliu 7y ago
How do you think the final step of DOM updates are done in any other libraries if not via DOM API calls?
- pcr910303 7y ago
  Well, React diffs the VDOM and decides what elements to update on runtime; Svelte decides the elements to update on compile time. That's the difference (and the meaning of 'compiling JS down into DOM API calls').
  - bufferoverflow 7y ago
    That's not true. I've been fighting with React rerendering every element of a long list when I change one element and update the context state. For some reason React rerenders everything, even when the keys are set and the references are the same. The only recommendation I got is to use React.memo, which still rerenders every element, but from some internal cache.
    - jbergens 7y ago
      I don't use context so I don't know if this is true or not. It might think it has to re-render since the context could affect anything below a component. It should however use the virtual DOM to diff first and not update the actual DOM more than needed. For class components in react you also have a special method shouldComponentUpdate that you can write to optimize things. But I feel we are into performance details now, it doesn't make the code hard to understand. You updated a value in the context and some component re-renderd, hopefully with the correct output.
- gridlockd 7y ago
  You usually don't need to debug the DOM API calls themselves, but the code close to that, causing the API calls to be made. The more convoluted and lossy the transformation between that code and the final code that runs, the harder things are to debug.

rimliu 7y ago

How do you think the final step of DOM updates are done in any other libraries if not via DOM API calls?

pcr910303 7y ago
Well, React diffs the VDOM and decides what elements to update on runtime; Svelte decides the elements to update on compile time. That's the difference (and the meaning of 'compiling JS down into DOM API calls').
- bufferoverflow 7y ago
  That's not true. I've been fighting with React rerendering every element of a long list when I change one element and update the context state. For some reason React rerenders everything, even when the keys are set and the references are the same. The only recommendation I got is to use React.memo, which still rerenders every element, but from some internal cache.
  - jbergens 7y ago
    I don't use context so I don't know if this is true or not. It might think it has to re-render since the context could affect anything below a component. It should however use the virtual DOM to diff first and not update the actual DOM more than needed. For class components in react you also have a special method shouldComponentUpdate that you can write to optimize things. But I feel we are into performance details now, it doesn't make the code hard to understand. You updated a value in the context and some component re-renderd, hopefully with the correct output.
gridlockd 7y ago
You usually don't need to debug the DOM API calls themselves, but the code close to that, causing the API calls to be made. The more convoluted and lossy the transformation between that code and the final code that runs, the harder things are to debug.