Why can't browsers use a virtual dom internally as an optimisation?

Question

There are lots of SO questions and blogs on the internet attempting to explain what virtual dom is, but this question is about why this kind of optimisation has to be to implemented in JavaScript/as part of a framework, rather than by the browser itself.

Virtual DOM, as I understand it, is a tree composed of Javascript Objects, with parents/children etc. but without most of the "heavy" features of the real DOM. Frameworks (e.g. React/Vue) respond to changes of model state by creating a virtual DOM from scratch and then do a diff on the last version of their virtual DOM to work out what real DOM to change.

Many of the things I have read, claim that virtual DOM is faster because real DOM has to re-layout (or even re-paint) every time there is a change, but this isn't true - re-layouts are only needed when some piece of JS code explicitly asks for some style/text-flow dependant value (such as a height/width etc.). And presumably most of the frameworks that use virtual DOMs cannot do any better at this - except ensuring developers don't accidentally do it.

Also, at some point recently browsers were considering providing event hooks for DOM-mutation, but that idea has been abandoned, meaning there shouldn't need to be any events fired at the point DOM is mutated.

So my question is, what does that leave in terms of benefits? What extra information, or extra freedom, does the JS framework have that gives it the "logical" power to perform the virtual DOM optimisation?

Answer 1

Virtual DOM is something like a workaround for the current situation. The W3C are working on re-building the DOM and make the current "virtual DOM" native to the browser. But you know how slow this goes - it has to be drafted, talked over, accepted, and then starts the fun part - implementing it in different browsers. They still have issues with CSS3 and flexbox model - every browser has it's own terms and standards for working with those.

And it's the same with the Virtual DOM - they still haven't accepted it to be a cross-browser solution. This will eventually happen in the future, but until then - we use the JS option.

If you follow the JS world - it was pretty much the same with Promises - we got the bluebird and jQuery implementations, but at the end Promises went native and all those libraries and frameworks are no longer needed.