> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development.
I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understands that virtual DOM is a means to an end. But then at the same time it is classified as a meme that only wins in performance against things nobody would ever do.
In a way, writing it like this makes it harder to critique.
At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.
Svelte’s approach requires detailed knowledge of the structure of state, and requires compilation: components’ <script> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics, and some places where JavaScript is too flexible to be tractable get replaced with special template syntax (like {#each} instead of for-loops or Array.prototype.map). Svelte cannot be implemented as a JavaScript library (I disqualify eval()). Svelte is also deliberately severely limited in what it can express in various places, whereas React gives you the full power of JavaScript (for better and for worse).
You could perhaps implement an optimising compiler for a small subset of React components that avoid problematic patterns and are written in TypeScript with proper specifications of the types of state and props; but if you considered it unacceptable for this compiler to change the component’s semantics, I think you’d be surprised at how little serious React code in the wild could actually be supported. Even simple loops might be out of reach. The Svelte approach can’t be a progressive enhancement, it’s an all-or-nothing (at the component level).
One could argue that React's hooks are the same: they look like JS but change JS semantics.
However, your point is still valid.
If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.
It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.
But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.This is probably true today, especially for newcomers, but the article is from 2018 and the context of the time period is significant here, I think.
Having used React since around 2015, there definitely was an aire of "React is fast because of the Virtual DOM!" and it was one of its big selling points early on. I can remember reading this article and nodding along, but reading it now evokes more of a sense of "I remember when VDOM mattered". I think around that time was maybe the tail end of VDOM being a big selling point, and this article might've even precipitated that, to a degree.
As React's usage has grown, I think the significance of VDOM as a feature has fallen by the wayside in favor of things like "everyone uses React so we use React too." The competition between frameworks at the moment seems less about performance and more about their approaches and tradeoffs.
The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.