While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html
> React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames
That's just cheating though, isn't it? And not in a good way. If you smear your DOM update over consecutive frames, you can maybe cram in 2-4x more operations in there before the user starts noticing. Past this point, a smeared update starts having design implications - things that should happen simultaneously now happen sequentially. Not to mention, application starts to feel heavy.
The only reason you need that in the first place is because of how expensive updates in react are. It’s lack of true reactivity and user-controlled memoization lead to a ton of trashing.
Svelte on the other hand is as optimized as possible - update the data, modify the corresponding DOM pieces directly. There is no realistic use case where you’d need to spread an update over multiple frames.
React's concurrent mode doesn't split DOM updates across animation frames because that would cause visual tearing. It splits all the component "overhead" and the virtual DOM cost over multiple tasks though.
