All you want to learn about Virtual DOM
Since the advance of react.js, software developers are also talking about the virtual DOM. Because React is using such technique internally, to make user interface updates faster.
What is a Virtual DOM?
The virtual DOM is a data structure that represents the your UI in Web Applications, mostly single page applications (SPA).
With treeact, I develope my own implementation of a virtual DOM. In its data structure each node, that represents also a node on the html Documents DOM, has only the three properties of tagName (a string), attributes (an object with key value pairs) and children( an array of more nodes and text content.
React is not using the same properties, not even plain object, but in the essence, the structure is the same. In react there are some extra properties to make its virtual dom even faster. More about that later.
Why do we need a Virtual DOM?
Reasoning about the UI. In React, when an event occur, that changes the state of the application, the app UI is re-rendered into the virtual DOM. That process creates a completely new version of the virtual dom. React.js will then take the current and the old version of the virtual dom and compare them. When there are differences, only the differences get updated on the real DOM.
By the way, just as the virtual DOM, the real DOM is also just a data structure. But it is the one used and displayed in the users browser window.
So, the biggest advantage of using the virtual DOM is reasoning. Because the UI is the result of a pure function following a simple formula state + function = UI. state is all the internal data of the app. The function is implemented by the app developer to ceate the vDOM and UI is what the user can see, once react updated the real DOM according to the vDOM. The process that react use, to update the UI, is called reconciliation.
Why is the virtual DOM faster?
There is the big process of creating the complete UI and comparing it to a previous version, and still to the updates to the actual DOM. How can this be faster? And the plain answer is: It just is.
Working with the browsers DOM is actually very very slow. It is so slow, that many engineers blame javascript to be slow. But the fact is, the DOM is slow. Each Node in the browsers DOM has more than a hundred properties and needs lot of memory. DOM elements cross reference each other, that makes memory management for a Node very expensive for the CPU.
For treeact, I build an XML parser. So the app developer can implement the UI using any already familiar templating engine. So the process was 1 creating an html string, 2. parse the html, and update the UI with a self implemented reconciliation process. This was fast enough to update a page with 5000 elements (comparable with pages in github and stackoverflow) 30 times a second.
That shows, that not JS is slow, but the DOM model in the browser.
Do not understand me wrong, this is not written to bash on the browsers, that they make the DOM so slow. The DOM in the browsers do so much more when changes happen. Such as handling events, applying css rules while doing a whole lot of memory management.
While treeact is cool, there are still good reasons to use react.js. Because it can do some more optimizations, to increase an applications speed even more, making it really possible to build animations with it.
One thing is the app developer can implement an optional method componentDidUpdate method for the components. This can often be a simple value comparison via tripple equal ===. This can tell react,that this part of the page dis not change. So it does need to do the reconcilation for this part of the age. It is.very useful for the page header and footer.
A second way, to optimize the reconcilation process, is to only rerender the part of application where the data has changed and all the rest of the app’s UI stay un touched.
With these optimizations, html apps can feel fast and snappy like native applications.
I head someone say, there is further optimizations possible, by running the actual apps logic inside a web worker and only to the UI updated in the frontend tread. But I have not seen any implementation of this idea.