Why can't browsers use a virtual dom internally as an optimisation? : <p>There are lots of SO questions and blogs on the internet attempting to explain <em>what virtual dom is</em>, 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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?</p>
