Note that a virtual DOM is pure overhead if you already have a real DOM to work with.
That's kind of the ignored superpower of a framework like React, which makes the virtual DOM the authority: there might be a DOM, but there also might not be. Whether the virtual DOM reflects to a real DOM, or native UI, or Qt, or an ASCII terminal interface, it doesn't care.
This is also the part that most web devs have the hardest time with: React (and some other frameworks) are not web frameworks. They really are just UI frameworks, that happen to (also) work in a browser. Even if they were original born out of a web need way back when.
Absolutely, but conversely: the performance hit of the virtual DOM _should_ (and that's doing a lot of heavy lifting) be irrelevant in a well designed UI, because aside from initial load, most parts of the UI don't change for the majority of the lifetime of the app. Only tiny portions of the UI update at a time. The parts that do update can most definitely update fast enough on even moderately modern hardware (both desktop and mobile).
That does, however, require having properly designed your UI, with a knowledge of where the power of your framework of choice is. And that's where a lot of apps fail. Even something as simple yet critical as using vdom keys tends to (for various reasons) never register for many folks, leading to terrible performance.
That's kind of the ignored superpower of a framework like React, which makes the virtual DOM the authority: there might be a DOM, but there also might not be. Whether the virtual DOM reflects to a real DOM, or native UI, or Qt, or an ASCII terminal interface, it doesn't care.
This is also the part that most web devs have the hardest time with: React (and some other frameworks) are not web frameworks. They really are just UI frameworks, that happen to (also) work in a browser. Even if they were original born out of a web need way back when.