The Walking DOM

#javascript #virtualdom #codechrysalis

This week, as a precursor to learning React, I studied the virtual DOM and attempted to create my own virtual DOM using JavaScript objects. It was a great exercise to help me understand that React creates a virtual copy of the the browser’s Document Object Model (DOM) and uses this for manipulations before writing to the actual DOM, but I wasn’t entirely sure why is makes sense to do it this way.

After some thought (and some conversations with people at Code Chrysalis) I can see the advantages.

The first thing that I realized is that there is more than one way to manipulate the DOM and different browsers can perform differently with the same JavaScript being called. Without getting into details I can accept that there are good and bad ways to update the DOM and secondly that updating the DOM can be an expensive operation.

Or said another way,

Updating the DOM can be slow.
But how does a virtual DOM (vDOM) help? If we capture all of our changes in the vDOM and then update the DOM, won’t that update be just as slow?

Because of my database background it helped me to think of the DOM as writing to disk and the vDOM as writing to memory. Writing to disk is a very expensive operation, and it is better to use memory for storing the data we want to manipulate before we commit it to disk.

Allow me to explain using zombies.

I have created a game where we get to kill zombies, but zombies of course come back to life. It is sort of their whole thing. Forget about the mechanics of the game, but on my web page I just want to display how many zombies are left. At the beginning we have 100 zombies.

The first case we have is a single change. I kill one zombie and update my vDOM to store 99 zombies. I check the differences and now I need to update the real DOM to show this.

I haven’t really saved any expense here. Perhaps the black box of React knows how to update the DOM better than I do, but for a simple change like this there isn’t going to be much savings.

Now I have 99 zombies, but I’m not done. I am a mediocre zombie killer and by the time I kill another zombie the first one has come back to life. When I kill a zombie I update my vDOM to reflect this (only 98 zombies left), but the first zombie has come back to life putting my count back to 99. I update the vDOM again. I check my vDOM differences and since nothing has really changed I don’t need to update the actual DOM. I can just leave it looking the same.

I have reduced my DOM manipulation by 100%!

Now a more complex situation is where I start killing zombies and I manage to kill them a little faster, but they also get faster at coming back to life as the game progresses. In the vDOM my updates might look like this:

Kill:100 => Kill:99, Ki3ll:99 => 98, Kill: 98 => 97, Respawn: 97 => 98, Kill:98 => 97, Respawn: 97 => 98, Respawn: 98 => 99, Kill: 99 => 98, Respawn: 98 => 99, Respawn: 99 => 100, Brains Get Eaten: 100 => 101

There are eleven updates to my vDOM, but it all happens so quickly that when I check my differences I only need to update the DOM a single time.

Another possible advantage of the vDOM is to make things simpler.

In addition to the savings I see by updating memory (vDOM) before I write to disk (actual DOM rendering) I can write my virtual DOM object so that it knows about zombies and what to do when they are killed. In a real world example the zombies would be HTMLElements of a specific type, but I think it applies.

I am looking forward to learning more about the virtual DOM and React in the coming weeks. That is, of course, if I am able to survive the coming zombie apocalypse.