Virtual DOM: Back in Block

Rate this content
Bookmark

Is the Virtual DOM pure overhead? In this tech talk, Aiden Bai explores the performance implications of the Virtual DOM in frameworks like React and presents an alternative approach called the \"block virtual DOM.\" Aiden delves into the origins of the Virtual DOM, its purpose in addressing performance issues, and the process of diffing and reconciliation. The talk introduces the Block virtual DOM, which takes a different approach to diffing by using static analysis and dirty checking.

9 min
12 Dec, 2023

AI Generated Video Summary

Hi, my name is Anand Bai. I'll be talking about virtual DOM and its performance. Rich Harris argued that the virtual DOM is not as efficient as many believe, leading to the emergence of the meme that it's pure overhead. Today, I'm going to introduce something new, a new approach to doing the virtual DOM. MillionJS, a drop-in replacement for React, is significantly faster than Preact and React on benchmarks. The block virtual DOM, introduced by Block DOM, is a potential solution to existing virtual DOM libraries like React.

1. Introduction to Virtual DOM

Short description:

Hi, my name is Anand Bai. I'll be talking about virtual DOM and its performance. Rich Harris argued that the virtual DOM is not as efficient as many believe, leading to the emergence of the meme that it's pure overhead. But when can the virtual DOM be slow? It's all because of the component that powers it. Let's take a look at how it works.

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.

2. Introduction to Virtual DOM (Part 2)

Short description:

First we check the first node. Has the first node changed? How about the second one? Yes, two has been changed to five. If we check the third one, we can see that the third node has been removed. The virtual DOM is really nice because it doesn't matter what the shape of their UI looks like. But what happens when you have more nodes? Today, I'm going to introduce something new, a new approach to doing the virtual DOM.

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.

3. Optimizing Updates with Edit Maps

Short description:

This could be a count or a node. We put a placeholder node in the tree for dynamic values. Traversing the tree, we create an edit map for each placeholder node. The edit map optimizes updates to the virtual DOM, resulting in O(1) changes. MillionJS, a drop-in replacement for React, is significantly faster than Preact and React on benchmarks.

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.

4. Million.js and the Block Virtual DOM

Short description:

Before, Million.js is better at rendering data-heavy and UI-heavy applications. The block virtual DOM, introduced by Block DOM, is a potential solution to existing virtual DOM libraries like React. Million.dev aims to enable writing React applications with a faster virtual DOM without any consequences. Check me out on Twitter at idynyy or visit million.dev.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn