Brief Origin of where the hype began
On the 29th of May, 2013, the pain of building interactive UIs on the web stopped, for on that day the open source library React.js was birth. It introduced features like JSX, Components, one-way data binding and more. One of the top features React brought to the table was the virtual DOM which we will get to in more detail later on. It was said to speed up DOM manipulation. In fact, Pete Hunt, a former React team core member, said that the virtual DOM was built to optimize performance. React later on became to be the most popular framework in 2021 by stack overflow, and it lived happily ever after. Well, not really. The creator of the most loved web framework in 2021, Svelte, Rich Harris called the virtual DOM a "Surprisingly resilient meme". At first I thought this was an unpopular opinion but when I started doing my extensive research (stalking senior developers on Reddit) I got to find out that Rich wasn't alone. In this article I'm going to go through why I might join the band wagon.
 at JSConfEU 2013](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fu6gqr8h0eyom7lryiroy.jpg)
Screenshot from Rethinking Best Practices at JSConfEU 2013
What is virtual DOM?
A virtual DOM is a lightweight JavaScript representation of the Document Object Model (DOM) used in declarative web frameworks such as React, Vue.js, and Elm. Put in simple terms, the virtual DOM is a JavaScript Object that stores data about how the DOM looks like at that instant. A way you can look at it is too see the DOM as an office, where all the furniture are elements (e.g. the table is the Nav bar, the chairs is the landing section, and the desk is a button). The virtual DOM is the blueprint of the office.
Why the virtual DOM?
When writing web pages and apps, one of the most common things you'll want to do is manipulate the document structure in some way. The default way of doing this is by DOM manipulation, i.e. using document.setAttribute() or document.createElement(). But one big problem with this was that once a change was made to the DOM the whole document would update. For example, you are building a company website and you need a form for clients to reach out to you, your form is there but you forget to put an input, so you update the form by putting an input tag inside of it. What happens behind the scene is that not only is the form updated but all the html elements(nodes) in the document, yup, all of it. You can imagine if you were building an e-commerce store with 10,000 items represented each in a div tag. That will be a very slow website. So this is where the virtual DOM comes in. The virtual DOM makes it possible for the DOM to only update what has only been changed. How does virtual DOM do it? well, there is this thing called diffing.
Diffing
Whenever there is a change in the state of your company website, a new virtual DOM is created. Then the new virtual DOM and the previous virtual DOM are compared with each other. This comparing is called DOM diffing.
The intention is to perform minimal operations on the real DOM, hence after diffing, the best way to update the real DOM is calculated, leading to an efficient update of your company website.
The following image shows the diffing process:
Why isn't the creator of Svelte buying into it?
As awesome as it may sound, virtual DOM does posses some bottle necks. let's go through them;
1. Developer's time is lost: Even though extreme levels of performance aren't one of them, virtual DOM brings a lot of benefits to the table. It's comparable to the difference between programming in Python or PHP vs. programming in C. More developer ergonomy comes at the expense of performance. In other words, it's a trade-off. You inherently write more code to get the job done.
2. It is not insanely performant: the implementation of virtual DOM in React is not highly performant as they say. If it was, why do they have React Fiber and shouldComponentUpdate(). React Fiber is basically used to optimize really heavy apps that require a lot of re-renders. the latter literally allows us to manually choose what component to update. I thought virtual DOM in React was all-encompassing, why are they providing these tools?
Conclusion
And just to be clear, I have nothing against React. Virtual DOM is just another round about in updating the DOM. Yes, it's performant and it gets the job done, but i've come to realize it isn't as perfect as they say it is.
Top comments (7)
Virtual DOMβ is more of a pattern than a specific technology. You'll need to update the DOM sooner or later so you'll end up manipulating the DOM anyways.
It will perform better or worse depending on the workaround you choose either be on the virtual DOM itself or playing with the DOM directly.
If we take a look at Angular and Vue:
Angular, doesn't have Virtual DOM, it uses its own mechanism for Change Detection combined with Zones, which helps Angular going through the Change Detection tree from its root to its leaves.
On the other hand, Vue uses the virtual DOM pattern as well.
You can take a look at performance metrics here: stefankrause.net/js-frameworks-ben...
I noticed that stefankrause.net needs an SSL cert upgrade but well.
Take it with a grain of salt as I'm not sure about what he's/they're running to benchmark this.
The credit goes to Svelte, but I'd say the virtual DOM approach isn't here to stay. React has gathered too much momentum to go away anytime soon, but I think it'll likely be shunned by startups and small teams.
shunned?
With your point 1 - I presume you mean "more code is executed" as there really isn't any more code written by the framework user.
We know Virtual DOMs can be fast - faster than Svelte, faster that Solid - ivi is the fastest according to Ryan Carniato (author of Solid) and Inferno can beat out Svelte and Solid too, it also uses a VDOM. There is a lot of complexity here and the flat out performance of a framework is not the only thing one needs to worry about - the developer experience and the mental model you can make is also very important.
React is looking at the whole lazy updates as things change, this is about allowing you to reason with the logic of the application and its user interactions - that's also an interesting area that can significantly improve the real world performance of an interface.
Not that I'm dissing Svelte, I love the way the framework operates and it is highly performant. I've built and released commercial software using it.
Depending on what you are building though there are many other important parts of the puzzle, Marko and its rehydration and streaming are also vital parts for web sites rather than apps as these must respond much more quickly.
At the end of the day, you need the rendering performance you need for each app, and you need a developer experience that makes building it easy. That may also include a library of components to use to make your app. You need to bear all of these considerations in mind and choose the right set for each individual project. Life as a software architect huh?
I think in the short term people should at least take a serious look at Preact as a React alternative, especially when React Native isn't a consideration.
... and for those less risk averse but pro-JSX perhaps even SolidJS
... perhaps (either) in combination with Astro if it fits:
From:
Marko for Sites, Solid for Apps
Ryan Carniato for This is Learning γ» Apr 25 γ» 7 min read
@knottjs is a tiny yet lightweight virtual dom library for creating and styling web component on-the-go. No CSS payload. Try it out!
Github (github.com/louislow81/knott.js)
I would love to know what you guys think about virtual DOM