The virtual DOM is more powerful than you think

If you're interested in the development world, you've probably heard of Virtual DOM - it's a representation of the real DOM created by JASCRIPT that libraries like React use to track responsiveness.

However, in recent years, many libraries and frameworks have questioned the effectiveness of the virtual DOM, and projects like Svelte and Solid have shown that fine-grained responsiveness is faster and easier to use than the abstraction of the DOM.

"this unlocks complete control over what gets updated and when, even at the dom binding level. with no virtual dom or extensive diffing, the framework never does more work than you want it to."

This will unlock full control over what is updated and when, even at the DOM binding level. With no virtual DOM or extensive diff comparisons, the framework will never go beyond what you'd like to do.

solidjs

Not really. It turns out that the capabilities of the virtual DOM are much more than many people realize - in fact, its functionality and usability are even far beyond the platform for which it was originally created, namely the Internet.

It all started in 2013 when the schema for the virtual DOM was released with React. The idea behind the virtual DOM is simple - to update in batches.

At that time, it was very painful to manipulate the DOM via j**ascript. Libraries like jQuery have made progress in improving this, but fast manipulation of the DOM can still have a performance impact.

The React team has come up with a different approach. Instead of updating every value and element for the sake of responsiveness, the changes are batched together and then pushed into the DOM at the same time.

Thus, the virtual DOM was born. By representing the DOM in j**ascript, changes and calculations can be made quickly before being pushed to the actual DOM.

Over the past few years, React has become the primary choice for developing responsive web applications, and it still is. It's easy to see why - markup languages are treated as functionsui = f（state）The idea is as simple as it is powerful.

That being said, it's clear that the virtual DOM isn't all smooth sailing. Just look at a recent example of a performance issue with React - the usememo() hook and React Forget.

In 2019, React released the UseMemo() Hook, which aims to solve a major problem with React performance. Because React tracks responsiveness, you'll often run into performance bottlenecks due to elements being updated unnecessarily.

To solve this problem, the React team introduced memorization technology to the library. Memoization is a technique for storing or caching values generated by time-consuming functions. By introducing the usememo() hook function, React developers can tell the framework when not to update elements, greatly improving performance.

But the introduction of usememo() further complicates what should be simplifying web development and breaks the previous logical flow of react.

To this day, React is still struggling to solve this problem. Recently, React has made progress in the library for a new compiler, React Forgot, which leverages profiling to automatically memorize at build time.

But while React Forget greatly simplifies the developer experience, it still requires a lot of work to solve a simple problem, as the compiler has to parse your UseMeMo() and intelligently identify which usememo() should be added in.

React Forget is still in development, but we've already seen its sights in production apps like the Meta Quest Store and Instagram, so more on that soon.

So, you might think, the virtual DOM doesn't make any sense. It's slow, makes the development experience worse, and doesn't even have a better advantage than traditional fine-grained responsiveness.

But while many of these points are correct, the virtual DOM has the grace to save the day, and that is that it makes React very powerful - the virtual DOM is not limited to web pages.

If you've ever created a react project, you know that you need at least two dependencies - react and react-dom. When I first got my hands on react, I thought it was weird, but the reason was because the react package generates a virtual DOM, and the react-dom package actually renders it into the real DOM.

What does that mean? Essentially, anyone can create packages that interpret the React virtual DOM and generate a variety of outputs. Rendering to the web via react-dom is just one way to do it.

We've seen this found application in many incredible libraries and frameworks. React Native leverages the virtual DOM to create native components for iOS and Android. Remotion leverages the virtual DOM to create real. mp4**。React Three Fiber enables you to render a full 3D scene using only React.

There really is no limit. There's even a project here developed by the incredible Poimandres team called:react-nil, it doesn't render anything - instead, it just lets you build servers and command-line interfaces via react abstractions.

The impact of this strategy is huge, as it means that React as a common interface can do almost anything from a computer. React's component and state thinking is very useful, and the virtual DOM makes this thinking ubiquitous.

Of course, with great power comes the consequences. A lot of times, React isn't the best way to do something, so it's important to think carefully about whether using React as the interface for anything you do is really the right way.

In conclusion, the virtual DOM is really powerful because it simply converts the component interface into an object and can be easily manipulated and interpreted in any way.

In this post, we're looking at it primarily through the lens of React, but other tools like Angular and Vue use a similar strategy, albeit with a difference.

Do you think virtual DOM is a revolutionary change, or an unnecessary abstraction? Is React really a general-purpose interface, or should it be limited to the web? Finally, what are your thoughts on using the virtual DOM to create something else? The possibilities are endless.