Virtual DOM is needed to enable a programming model where in each UI iteration, you return the entire UI tree anew. Actually creating a new DOM tree anew would be terribly wasteful, and you might lose lots of state (e.g. half entered text or selected text or something) so instead you do dom-diffing. For some reason, people consider that model to be more hip than the normal one where you take care of updating yourself. Probably because writing code to create the entire UI tree anew is more easy to write, but tbh it's also more wasteful. Classical ease of use vs computation tradeoff.
>For some reason, people consider that model to be more hip than the normal one where you take care of updating yourself.
A huge benefit of the virtual dom model as used in React is that you don't need to have separate code paths for the initial render of a widget and updating part of a widget. I can't count the number of times I've seen pre-React widgets coded to assume most attributes would never change, had bugs in updating some uncommonly-updated attributes, or gave up on having separate initial-render/update code paths by throwing away the widget's entire DOM and re-rendering on most attribute changes. With the React way, there's one code path for initial render and updating, so it doesn't take any special effort to make every attribute efficiently update-able. A whole category of bugs disappeared in codebases I've worked on that adapted React.
It's not because it's "more easy to write". It's because code that generates the entire tree every time can be side-effect free, while stateful UI is, well, stateful.
We can debate if that's good or not, but it's not about "ease of use". Neither is it necessarily more wasteful. It's a different paradigm.
