If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.
Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here. In practice. So Svelte has a lot to prove to get people to try to move. And this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” (while simultaneously admitting that plenty of frameworks were slower at the time.) That’s not going to work. That’s going to classify you as “insane person” to many people. It reminds me of the claims G-WAN made: over-exaggerations in a smarmy tone based on micro-benchmark wins.
I’m not saying there’s anything wrong with Svelte. But, this is not how you sell something. React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. It delivered exactly that. And yet:
> the alternative is to do something no-one actually does
Somehow this article manages to contradict itself in pursuit of unnecessary smarminess.
I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion.
The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.