Before we dive deeper into this topic, it’s best if we revisit what the original DOM, or Document Object Model, is.
According to MDN,
“The Document Object Model (DOM) is a programming interface for HTML and XML documents. It represents the page so that programs can change the document structure, style, and content. The DOM represents the document as nodes and objects. That way, programming languages can connect to the page.
Well, this sounds awesome. Why do we need anything more?
That’s a great question! I was wondering the same thing. To answer that, let’s dig a little more into the structure of the DOM.
When the HTML DOM renders, it has a tree-like structure. This is beneficial for us as developers because we can traverse through the tree fairly easily. However, easily does not mean quickly. Let’s not forget that these DOM trees are becoming increasingly bigger nowadays, with endless divs and numerous methods that handle events, etc. In addition, because of the DOM’s tree-like structure, any top level changes can cause huge ripples to our user interface (UI). Extensive DOM manipulation is performance heavy, can lower your app’s overall performance, and may even result in an unpleasant user experience. This proposes a problem in our ability to manage all the different parts of our code efficiently.
This is where the “virtual DOM” comes in.
The virtual DOM is an abstraction of the HTML DOM that is not bound to any specific browser. This technique was not created by React, but its use was greatly popularized by React. You can think of the virtual DOM like React’s local snapshot of the real DOM that is more simplified and lightweight — it’s literally a “virtual” representation of the real DOM. It has all the same attributes as the DOM but lacks the ability to directly change what is displayed on the screen until the real DOM is updated. This allows React to take the abstracted copy and alter it without utilizing any actual DOM operations, which are usually very slow.
Manipulating the DOM directly can trigger layout changes, tree modifications and re-rendering each time something is changed. For example, if you made edits to 50 nodes one by one, you would have 50 potential recalculations of the layout, 50 potential tree modifications, and 50 potential re-renderings. Definitely not something that sounds efficient.
So how does the virtual DOM help us?
Because React creates a tree of custom objects representing a part of the DOM, it can change these objects without actually having to touch the real DOM. For example, when we want to create a div element that has a ul element in it, React will instead create a React.div object that has a React.ul object in it. We can then can manipulate these objects very quickly while never touching the real DOM.
When we want to actually render the newly modified components, React will utilize two virtual DOMs — one that has the updated state and the other one that has the prior state before any new changes were made. Then, React will use these 2 virtual DOMs to figure out what specific parts need to be updated to make the two trees match in an algorithmic process, called “diffing.” Once it finds which virtual DOM objects have been altered, it will update only those objects in the real DOM.
For instance, if we make a change to one item in our list, React would only update that one specific item and leave the rest of our list untouched. It will then take these changes and do a batch update to the real DOM so we can re-render the new changes to our UI.
To join our community Slack 🗣️ and read our weekly Faun topics 🗞️, click here⬇