Virtual DOM

What you know might be insufficient

I have been playing with vuejs for a while now and I must say, the experience has been amazing so far. I recently heard Thorsten Ball, the author of the interpreter book being interviewed on the Gotime podcast. He was talking about his monkey programming language he built using Go.

One great thing I learnt from his interview was, we must be willing to at least understand the layer or layers of abstractions we are working on top of. While this might seem like a daunting task, it is really an important one.

This are the things I am going to cover in this article.

• What is a virtual DOM ?
• Why virtual DOM ?
• What is wrong with the DOM ?
• Is virtual DOM faster than the DOM ?

What is a virtual DOM ?

Virtual DOM is a virtual representation of the DOM. In other words it is an abstraction of the DOM. Most virtual DOM implementations are javascript based. Virtual DOM is nothing magical, it is just a plain object. Let’s say we had the below DOM representation.

<ul>
  <li>First Item</li>
  <li>Second Item</li>
</ul>

This is how you would represent the above as a javascript object.

var vnode = {
             ul:{
                li: "First Item",
                li: "Second Item"
                }
            }

Why virtual DOM ?

For you to have a better understanding of why you might want to use a virtual DOM, you must look at the problems that led us to the virtual DOM.

• The DOM trees are huge nowadays. Since we are more and more pushed towards dynamic web apps (Single Page Applications SPAs), we need to modify the DOM tree incessantly and a lot. And this is a real performance and development pain.
• The DOM is bloated. Every time you touch a node just to read an attribute or a class name, or to get to a child or sibling, the browser has to search, check, parse a rather large number of properties and values for each node. The modern browsers are all spectacularly fast and efficient at doing this, but problems arise when you try and manipulate a large number of nodes.

The virtual DOM concept

So Let’s take an example. A very naive, though. If you have something messed up in your room in your home and you need to clean it, What will be your first step? Will you clean your room which is messed up or the whole house? The answer is definitely you will only clean your room which requires the cleaning that’s what virtual DOM concept does.

Whenever you have any changes i.e. you want to add another div to your DOM then the virtual DOM will be created which actually does not do any changes in the actual DOM. Now with this virtual DOM, you will be checking the difference between this and your current DOM. And only the part which is different in this case the div newly added will be added instead of rendering whole old DOM.

This does not get rendered at all, so changes to it are cheap. Then, you dump those changes to the “real” DOM. You do that once, with all the changes grouped into 1. Layout calculation and re-rendering will be bigger, but will be done only once. Grouping all the changes into one is what reduces calculations.

But actually, this particular behaviour can be achieved without a virtual DOM. You can manually group all the DOM modifications in a DOM fragment yourself and then dump it into the DOM.

So, again, what does a Virtual DOM solve? It automates and abstracts the management of that DOM fragment so you don’t have to do it manually. Not only that, but when doing it manually you have to keep track of which parts have changed and which ones haven’t (because if you don’t you’d end up refreshing huge pieces of the DOM tree that may not need to be refreshed). So a Virtual DOM (if implemented correctly) also automates this for you, knowing which parts need to be refreshed and which parts don’t.

The DOM

The DOM is an API that provides a structural representation of a document. It defines a way that the structure can be accessed from programs so that they can change the document structure, style and content. Normally this structure is in a tree form.

The browsers handle the DOM implementation details and provide us with the DOM API with which we are able to access, change, delete or add any part of a document.

The DOM is not the same as html. The html you write is parsed by the browser and turned to a DOM (Document Object Model). To illustrate the difference let’s look at an example.

Note : In the above example, we have not declared a /. When we load this into the browser and look at our devtools pane, we find that there is a added. What you see below is a visual representation of the DOM.

The browser’s workflow.

Creation of the DOM tree - Once the browser receives a HTML file, the render engine parses it and creates a DOM tree of nodes, which have a one-one relation with the HTML elements.

Creation of the Render tree - Meanwhile, the styles both from external CSS files, and inline styles from the elements are parsed. The style information, along with the nodes in the DOM tree, is used to create another tree, called the render tree.

Creation of the Render Tree — Behind the scenes

• In WebKit, the process of resolving the style of a node is called “attachment”. All nodes in the DOM tree have an “attach” method, which takes in the calculated style information, and return a render object (a.k.a. renderer)
• Attachment is synchronous, node insertion to the DOM tree calls the new node “attach” method
• Building a render tree, consisting of these render objects, requires calculating the visual properties of each render object; which is done by using the calculated style properties of each element.

The Layout (also referred to as reflow)

• After the construction of the render tree, it goes through a “layout” process. Every node in the render tree is given the screen coordinates, the exact position where it should appear on the screen.

The Painting

• The next stage is to paint the render objects — the render tree is traversed and each node’s “paint()” method is called (using browser’s platform agnostic UI backend API), ultimately displaying the content on the screen.

What’s wrong with the DOM ?

Whenever you make a DOM change all the following steps in the flow, right from the creation of the render tree (which requires recalculation of all the style properties of all the elements), to the layout, to the painting step, all are redone.

In a complex SPA, often involving a large number of DOM manipulations, this would mean multiple computational steps (which could be avoided) which make the whole process inefficient.

The real problem with DOM manipulation is that each manipulation can trigger layout changes, tree modifications and rendering. Each of them. So, say you modified 30 nodes, one by one. That would mean 30 (potential) re-calculations of the layout, 30 (potential) re-renderings.

Is Virtual DOM faster than the DOM ?

People often throw around the statement “The DOM is slow”. This is a completely false statement. Why is the browser DOM so slow, that all of that overhead with the Virtual DOM and diffs is still faster? The DOM API methods are still called under the hood. The virtual DOM is more efficient than direct DOM manipulation because it patches the DOM with the necessary changes avoiding unnecessary repaints and re-renders.

If you found this information useful, please like and share it with your colleagues.