Virtual DOM exposed

Christian Lisangola — Wed, 31 Mar 2021 21:01:01 +0000

For a while, I was wondering why several articles and tutorials about React say that the virtual DOM makes web applications made with React.js perform better because of the way React.js updates the DOM or real DOM.

Here are the questions that made me look into the deeper workings of the virtual DOM :

When working with the DOM directly, does a change to a single element or node trigger a refresh of the entire DOM?
Are browsers that stupid to render the whole DOM tree just because there is a change on an element?
If I were to create a browser, knowing the costly operation of rendering which includes painting, layout calculation, etc., does it make sense for me to let all this costly process repeat every time there is a change?

The purpose of this article is not to deny the importance of the virtual DOM, but rather to expose what it is not as it is presented here and there in several articles and even tutorials, and to give my point of view on the issue as I have experienced and understood the inner working and role of the virtual DOM.

Before going any further, let's talk about the DOM itself.

DOM

When you write your HTML, in a .html extension file it is so that ultimately it can be read by a web browser in order to display its contents.
The HTML code you write represents the blueprint from which your browser will build the DOM which stands for Document Object Model..

Why Document? Why Object? Why Model?

Your HTML Document is the Model from which the browser will create the tree structure of your page so that Javascript has a representation in the form of an object that it will know how to manipulate.So, you know what DOM means.

Let's say your HTML code is as follows:


<!DOCTYPE html>
<html>
  <head>
    <title>Learn code</title>
  </head>
  <body>
    <h1>Programming Languages</h1>
    <ul>
      <li>Java</li>
      <li>Go</li>
      <li>Typescript</li>
    </ul>
  </body>
</html>

DOM tree for the above HTML Code

Once the DOM tree is built, you can use a Javascript API to access these elements to modify their content, delete them, create new elements, etc.

As Javascript has an object representation, there are methods for manipulation such as document.getElementsByTagName('li') which returns a collection of li's or a document.createElement('p') to create a paragraph element. Then these created elements can be added to the DOM.

Now let's go back to the virtual DOM of React.js

What is really the virtual DOM?

Before we talk about the Virtual DOM, we need to think about how React.js works and especially its rendering cycle.
In React.js user interfaces are broken down into reusable pieces of code usually written in JSX(Javascript Syntax Extension)language.

If for example we want to reuse a button in several places in our code, we can create a button component which is completely independent and which can be grafted in other components.

In React.js a component can have data that represents its state, and when that state is updated, the component must rerender.

RERENDER!!!!
Here is the origin of all the confusion and misunderstanding of the Virtual DOM.

Imagine that we have a rather complex component that represents an important block of your web page, and its state is updated.Then imagine again that if it's just a very small part that changes but according to React's philosophy, the whole component should rerender.If this change should directly be applied on the real DOM that will include includes repainting, layout calculation, etc..It will coast too much in terms of performance.

So React developers had to find a solution to avoid unnecessary DOM updates, and this solution had to help React minimize the performance cost of such an operation.

In the manipulation of the real DOM, there is no complete rerender when a part has changed because it is possible to target specific elements of the DOM and apply changes to them that will not impact the whole document, so to say that with the real DOM there is a rendering of the whole DOM every time there is a change is completely false and unfounded.
If React solves the problem in terms of the performance, it's because of it own rendering cycle.

The way React.js uses the virtual DOM to solve its own problem is that every time it makes sure it has a copy of the DOM in the form of a Javascript object, and when the state updates, React creates another version of the virtual DOM that is another Javascript object that is a newer version with the updated state. Then it will apply a diffing algorithm to detect which parts have changed and then apply its changes only where needed in the DOM, so that at some point React also ends up doing the expensive operation by touching the DOM even if it is more efficient because the whole DOM is not refreshed.

In my opinion, one of the biggest advantages of Virtual DOM is the developer experience, because thanks to this philosophy, React offers us a declarative API that saves us from writing code to do the DOM manipulation in an imperative way. From a development perspective it is a huge advantage and time saver to write declarative code with JSX than code written with Vanilla Javascript or libraries like Jquery. This code written in JSX will then be translated into Javascript code that allows for the creation of React.js component instances.

If you have other questions, a contrary opinion or additional information do not hesitate to put them in the comments.

DEV Community: Christian Lisangola

Virtual DOM exposed

DOM

Why Document? Why Object? Why Model?

DOM tree for the above HTML Code

Now let's go back to the virtual DOM of React.js

What is really the virtual DOM?