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?

Indium

This discussion shouldn't be about Virtual-DOM, but about the actual concept of only changing the nodes and attributes that should be changed. For example setting document.body.innerHTML = tonsOfHTML should not replace everything blindly but do a super fast check & update only what should be updated, regardless of the term "virtual DOM" (which I dislike) – Cattleya

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.

Pedicle

But why can't they use a virtual dom internally as an optimization of regular dom? – Indium

Because what is called "Virtual DOM" now is written in JavaScript and no real browser would be developed in it :) And of course, as I said - currently there is no standard so each browser implements it the way they want. When there is one - they will try to do that. – Pedicle

I'm not asking about a public api..I'm asking why the browser isn't using the same "tricks" that virtual dom uses, and hiding the details from the JS developer – Indium

The Virtual DOM is mostly used in reactive applications where there is a common changing/re-rendering of specific elements. Or a lot of DOM manipulations. Not everything on the web is reactive, as well as the DOM itself does much more than just that. And there should be a standard, because for example Virtual DOM can batch specific operations, while the regular DOM must execute them straight away, as it's the way it's built. They have to change the intended way of working, which will introduce new problems. Therefore - a unified approach should be selected. – Pedicle

I get that, but surely regular dom can batch until the next frame, so long as the JS doesn't ask too many questions – Indium

I don't understand what DOM implementation has to do with JS - they are two separate worlds. No browser is built upon JS. Also there are rules, that currently apply - you cannot just like that make wild guesses if the user wants the operations batched or not. Virtual DOM also includes reusing nodes, changing their values, instead of removing/adding new ones. This is totally out of the scope of the DOM itself. – Pedicle

Because changes to DOM are only observable by (a) the end-user on the next frame, and (b) any JS which is asking questions about styles/layout. As long as the browser satisfied the expectations of those two parties, then it can do what it likes behind the scenes. – Indium

Any link to the W3C spec proposal for this? – Fighter

As I remember and read somewhere, Facebook faced a lot of challenges so far due to which they starting their own dom. They spoke to browser owners, some agreed and some did not. Because not all browsers have all the latest updates on current JS solutions as well. So we use transpilers. Expecting all browsers one day soon to have this uniform. There will be a lot of disagreements, but open-source platform developers are there to solve. – Platitudinize

Answer 2

A new browser called RTA is trying to implement virtual dom in their browser design and its going to change the way browser works.I hope we will be able to see the difference soon...

Scout

any affiliation? /help/promotion – Thermostatics