Check out a free preview of the full Vue 2 Internal Features from the Ground Up course

The "Virtual DOM" Lesson is part of the full, Vue 2 Internal Features from the Ground Up course featured in this preview video. Here's what you'd learn in this lesson:

Evan reviews virtual DOM, which is a lightweight representation of what actual DOM should like at a given point in time. Virtual decouples rendering logic from actual DOM allowing rendering capabilities in non-browser environments such as server-side and native mobile rendering.


Transcript from the "Virtual DOM" Lesson

>> Evan You: So what is a virtual DOM anyway? The actual DOM, most of us know the native DOM API. For example document.createElement, we can create a real div node that represents this div in our actual document. So this is native API. And it's internals are in fact implementing C++ by the browser engine.

We don't actually get to touch most of it. It just exposes the API in JavaScript for us to work with it. In comparision, the virtual DOM in view, on each instance there's actually this $createElement function which returns a virtual node that also represents a div. But it's just pure JavaScript.

It's just an object.
>> Evan You: The difference is actually pretty huge. Because as you know, if you log a div's properties inside the browser, you'll see that a real div node have so many properties. And the underlying implementation is in fact pretty heavy. And also, because we are essentially calling this native code via a JavaScript interface, there is this cost of communication between the two sides.

And it's going to be more expensive than, say, doing pure Javascript operations in pure Javascript land. So this is why a lot of times we say if you touch the DOM, things get slower. In some browsers, they might optimize that. But in general, there is this slight overhead when you are reaching to native stuff from the JavaScript side.

>> Evan You: So as you can see, the virtual DOM div is just an object. It has a tag that tells us it's a div. It has a data object, which contains possible attributes. If it doesn't have any attributes, it doesn't even need to have a data object. And then it can have a list of children, which is an array of more virtual nodes, so now we have a tree of virtual nodes which constitute the virtual DOM.

>> Evan You: So this is just very high-level understanding. Virtual DOM is cheaper than the actual DOM, right? So let's say we have a list of 1,000 elements. Creating 1,000 JavaScript objects is pretty cheap. It's pretty fast as well. But creating 1,000 actual div nodes is much, much more expensive, okay?

>> Evan You: So this virtual DOM is essentially a lightweight JavaScript data format to represent what the actual DOM should look like at a given point in time. This is important because we're generating copies of virtual DOM on every update. This is only made possible because virtual DOM is cheaper than real DOM is.

If we, say, use inner HTML to update our app, we're essentially throwing away all the previous DOM nodes, real DOM nodes, regenerating all the real DOM nodes again. So this cost is much much more expensive than, say, just generating a new virtual DOM snapshot. And inner HTML also has a problem.

It throws away the current state on, say, form input elements and all that stuff. But a common misunderstanding is virtual DOM is what makes a lot of these frameworks fast. It does not. Virtual DOM is just a way to get around the limitations of the original DOM so that it enables this paradigm of declaratively composing what you want the DOM to look like.

So this unlocks a bunch of possibilities. But there's also this comparison between,
>> Evan You: Well, I'll talk about it later. Another benefit of the virtual DOM is that it decouples rendering logic from the actual DOM, right? So we have the steps of diffing, then we apply those changes to the DOM.

If we throw away the last step, all of our apps updating logic can actually be executed virtually. It doesn't need to ever touch the DOM. And in fact, if we abstract out these eventual connecting points, API's that touch the DOM and then sort of redirect them to other places.

We can create the same app running virtually in any environment that supports JavaScript, but it doesn't necessarily have to touch the DOM. Instead, it can talk to a native rendering engine, for example, iOS or Android. Or on the server side, we can turn the virtual DOM into strings or a string finder.

So making a virtual DOM talk to a native rendering instead is what enables projects like react native, weeks, native script. They all have this similar architecture where the JavaScript app runs virtually inside an embedded JavaScript engine. And it only sends the necessary messages about, after say diffing, or any actual node operations send to the render aside.

So this is the architectural advantage of virtual DOM. Obviously, virtual DOM is not the only way to achieve that, but it's a pretty good way to do that. And render function, finally, it's just a function that returns Virtual DOM. Okay, so templates in VJS are compiling to render functions by the compiler.

So we have a little app called View Template Explorer, which you can use to sort of get a, you can explore how the templates are compiled into render functions. But we'll talk about what render functions actually look like in more details later.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now