Virtual DOM: Back in Block

Hi, my name is Anand Bai. I'm the author and creator of Millionjs, a fast virtual DOM replacement for React. I'm also a student at the University of Washington for CS. Actually, this is my dorm right here. So today, I'll be talking to you guys about virtual DOM, but this time, back in block.

A little over 4 years ago, Rich Harris released Virtual DOM is Pure Overhead. Rich most notably said, you've probably heard the phrase, the virtual DOM is fast, often meant to say that it's faster than the real DOM. In fact, it's a surprisingly resilient meme. In his article, Rich Harris argues that virtual DOM, a widely praised feature of frameworks like React, is not as efficient as many of us believe. He goes on to critique the way it works and presents Svelte. But what followed years after was the emergence of a new meme, that the virtual DOM is pure overhead. The meme became so resilient that it turned the no-virtual DOM framework movement from an iconoclastic subgroup to a fully fledged crusade. Thus, the virtual DOM was relegated to the annoying-cousin-nobody-likes-but-has-to-invite-to-family-gathering status. It became a necessary evil, a performance tax that we had to pay for the convenience of declarative UIs... until now.

So the natural question everyone, or you guys, are probably asking is... Why is the virtual DOM slow? But I think a better question to ask is... When can the virtual DOM be slow? And it's all because of this guy. You've probably heard of his music video. I don't actually mean this guy, but rather the component that powers him. Let's take a look. One branch is a code return unless you're AngularJS if math.random is over 0.5. It can also return a RIC rule GIF. So you can see here naturally that there could be an update between the RIC rule and the AngularJS. So how does this work? Well, here's where the virtual DOM comes in. So the virtual DOM is essentially a tree or data representation of the user interface, or in this case, the DOM. You can see here that there are five nodes in the old virtual DOM tree. And there's three nodes in the new one. So how do we update the user interface based on these trees? Well, we run a diff. So we traverse both trees at once.

First we check the first node. Has the first node changed? I don't think so. How about the second one? Yes, two has been changed to five. And so what we can do here is do a DOM update. It's just like doing .innertext or replacing a node or whatever. Let's go on.

If we check the third one, we can see that the third node has been removed. And so we can remove it in the DOM, so on and so forth. You can see here that the virtual DOM is really nice because it doesn't matter what the shape of their UI looks like. It doesn't matter how much nodes we have. Eventually we can process all of them and do the minimal amount of DOM updates to the page. So this is great. Essentially, you can change old UIs to new UIs using this virtual tree structure.

But what happens when you have more nodes? You're doing five diffs. It's nice when you have five diffs because you're going to have to change five nodes anyway. But what happens when you only change one node? Well, you still have to do five diffs here. You have to check if foo is the same. And in this case, you only update one. So this can get really inefficient. So imagine it as O of n. As your UI gets bigger, the more you have to diff, and the slower your app gets. And here's a visualization of that. Once you have 200 nodes in your page, it gets really slow.

So today, I'm going to introduce something new, a new approach to doing the virtual DOM. Instead of diffing the tree structures and doing all this stuff, what if we just diff the data and not the DOM? Well, this all starts with a compiler. The compiler can look at the virtual DOM ahead of time. So we still have this tree structure here. It's just not in the runtime. So here, we know the relationship between the data and the UI here. So you can imagine in React you have a use state with a count and whatever.

This could be a count, or this can be a node in our case. We don't necessarily know the values beforehand, and so we put a placeholder node inside of these. So essentially, we have this tree, and the dynamic values that are put in the nodes are marked as potentially could be a value there.

And so what we do now is just traverse the tree like is usual. We check the first one as a placeholder, so on and so forth, and when we hit a placeholder, we can create something called an edit map. This is the secret sauce of the block virtual DOM. Essentially, what we say is when node 1 changes or this data changes, we change this node. Essentially, we have this relational mapping between the data and the UI. And we can do this for every single placeholder node on the tree.

And during runtime, the edit map really, really shines. You can see here when we're trying to update node 1 and node 2's value to 3 and 4, respectively, you can see that we only have to do two diffs. So we check if the data is the same, 1, 3, yes, it has changed. Check it again, it has changed. And we can make updates to the virtual DOM. You notice here that the virtual DOM would take five diffs, but with the block virtual DOM, it only takes two. And this scales infinitely. This is essentially an O of 1 optimization to the virtual DOM. And this is really cool, because we have the same example of 200 nodes on the page. Now you can see that the change is O of 1. Every single time you update, there's an O of 1 change. And it's really, really fast.

So I work on a project called MillionJS. It implements the block virtual DOM as a drop-in replacement for React. Using that, it is 30% faster than Preact, which is a lightweight React alternative, and over 70% faster than React on synthetic benchmarks. And so this is really, really indicative of better performance using the block virtual DOM, particularly on benchmarks compared to traditional virtual DOM alternatives. So essentially, MillionJS and the block V DOM are faster than React. And if you don't believe me, you can take this example. I have a really bad computer, so bear with. When I click on this button, it's really, really red, and that's indicative of bad performance. But when I switch to Million, when it loads, if it doesn't beach ball me, you can see that when I click here, it's way better.

Before, it was just a plain red. It was a bloody red-like circle, but now it's in the greens and the yellows. And so Million is way better at rendering lots and lots of data-heavy and UI-heavy applications.

Thank you so much for listening. This is just a brief lightning talk of my work on Million.js and the block virtual DOM. There is so much research to be done in this field. The block virtual DOM was originally introduced maybe two years ago by a project called Block DOM. There's so much more to be figured out, researched, and introduced. Just like signals, the block virtual DOM is a potential solution to existing virtual DOM libraries, like React particularly. And this is my mission with Million.dev. What if we were able to write our React applications with this faster virtual DOM and not have to pay any of the consequences for it?

And so if you're interested, check me out on Twitter at idynyy or check out my project, million.dev on the interwebs. Thank you so much for listening. Have a great day.