Very few apps that use React require sustained, fast DOM changes for a long period. Most web apps sit idle 99% of the time, and then need to manipulate a handful of DOM elements based on a user action - the user clicks a button or types in a box and a few things around the page update. That means the framework needs to make 4 or 5 DOM changes in one frame (about 10ms including the browser's overhead to render things.) The fact that this is slow in some web apps is beyond disappointing. They're doing
practically nothing and they still feel terrible.
This is where I think React is getting things right. The work that's been done on React 18 attempts to work out what events are most important, and schedules the DOM changes from those interactions ahead of changes from other events. It batches the changes over a number of frames if there's a lot of them. This means that a UI made with React will probably be slower than other frameworks, but it'll feel faster. The changes that result from your interaction happen first. That's what users want.
Ultimately every framework has an upper bound for performance, and if you're not hitting it then the framework speed doesn't really matter. If you are hitting it though, then React's approach is better because it optimizes for the bit the user cares about. The fact that Solid, Svelte, etc are technically better, and therefore faster, means there's lots of additional headroom for using that speed, but once you actually cross the threshold of what they can do things will start to feel slow very quickly.
And this is where that matters - many web developers just aren't great at writing code, so if the framework can scale a 'fix' for what they build that will result in a better user experience than simply giving the developer more speed. A faster VDOM is a good thing, and no VDOM at all is an even better thing, but ultimately you could make the fastest framework ever and some developers will still write things in ways that feel slow.
The right approach for fixing UI on the web is to make a framework that focuses on doing the important DOM changes first, even if it does them a bit slower than the other approaches.
This is where I think React is getting things right. The work that's been done on React 18 attempts to work out what events are most important, and schedules the DOM changes from those interactions ahead of changes from other events. It batches the changes over a number of frames if there's a lot of them. This means that a UI made with React will probably be slower than other frameworks, but it'll feel faster. The changes that result from your interaction happen first. That's what users want.
Ultimately every framework has an upper bound for performance, and if you're not hitting it then the framework speed doesn't really matter. If you are hitting it though, then React's approach is better because it optimizes for the bit the user cares about. The fact that Solid, Svelte, etc are technically better, and therefore faster, means there's lots of additional headroom for using that speed, but once you actually cross the threshold of what they can do things will start to feel slow very quickly.
And this is where that matters - many web developers just aren't great at writing code, so if the framework can scale a 'fix' for what they build that will result in a better user experience than simply giving the developer more speed. A faster VDOM is a good thing, and no VDOM at all is an even better thing, but ultimately you could make the fastest framework ever and some developers will still write things in ways that feel slow.
The right approach for fixing UI on the web is to make a framework that focuses on doing the important DOM changes first, even if it does them a bit slower than the other approaches.