DEV Community

Vani Shivanand
Vani Shivanand

Posted on

Is Virtual-DOM Needed? A Simplified Example

Before we start, let's see if the browser DOM is slower than all the javascript code that's executed on the javascript engine.

Instead of all the Virtual DOM code, let's take a very small javascript snippet where an array collects the incremented number over a loop. After the loop ends, it adds an array of numbers to the DOM.

In the second case, let's update the DOM inside the loop on every increment.

Here is the screenshot from jsperf where a small test case was written to compare. And the result looks as shown below,

Alt Text

The results clearly show that updating DOM for every increment is 100% slower than a javascript snippet execution and to update the DOM only once.

Let's See Why It Is 100% Slower?

To revisit basics, Javascript engine executes all the code first and then DOM plus CSSOM has to be ready. Only after that, the first pixel on the screen will be painted.

DOM is to Browser Engine & Javascript is to Javascript Engine. Whenever a DOM update happens, both the engines need to communicate bringing in the lag.

Due to workflow that happens before the first paint, every time the DOM is updated via javascript code domElement.innerHTML = "someValue", the CSSOM also needs to complete. It adds further to the delay. Again the next line of javascript code is run. This needs the switch between the execution by javascript engine and browser engine unless defer or async tags are used.

Virtual DOM Helps

Virtual DOM having a tree that's stored and executed by javascript Engine itself makes things a lot less slow.

  • The number of times both the engines communicate reduces.
  • There is no need for CSSOM to complete as the styles need not be applied in Virtual DOM.
  • Every time the Virtual DOM updates, there is no switch of execution as it is run by only Javascript Engine.
  • Though it is a good practice not to update the Virtual DOM also whenever it is not needed, there is quite a good margin on performance loss that can spoil our application performance.
  • This means smooth user interaction, faster first paint time and hence a better SEO ranking as well.
  • We are not even speaking about efficiently writing a Virtual DOM. Yet, it is beneficial if we just take care of very few scenarios too.

From all the cases, for now, Virtual DOM is a lot beneficial. This will continue to be the same unless the browsers come up with a strategy to address the DOM update delays.

A comment on the above reading would be a lot helpful for me to improve my writings further. Thanks for the time!

Discussion (7)

Collapse
momander profile image
Martin Omander

I learned something new, and in only two minutes of reading! Thanks for keeping it short and concise, and including real performance data. Well done!

Collapse
svaani profile image
Vani Shivanand Author

Thanks a ton Martin. That motivates me to write more.

Collapse
leontepe profile image
Leon Tepe

I'm sorry but this is so unbelievably stupid.

Collapse
karkranikhil profile image
Info Comment hidden by post author - thread only accessible via permalink
Nikhil karkra

You don't need Virtual DOM. Learn Svelte.js

To understand more go though this video by Rich Harris
youtube.com/watch?v=AdNJ3fydeao

Collapse
svaani profile image
Vani Shivanand Author

Nikhil Karkra,

Here it is Svelte Needs A Virtual DOM. Please feel free to discuss on the same if anything looks not convincing.

Thanks!

Collapse
karkranikhil profile image
Nikhil karkra

Sure I would love to read it.

Collapse
svaani profile image
Vani Shivanand Author

Nikhil Karkra,

Thank you for the comment.

I will make another post on "Why Virtual DOM is still needed, even after Svelte features"

Some comments have been hidden by the post's author - find out more