Virtual DOM Is Not a Silver Bullet

For a long time I was wondering, what the magic was behind the Virtual DOM. I’ve heard a lot about how it boosts rendering performance but I never understood exactly how. So I decided to finally figure it out for myself.

Virtual DOM introduces an abstraction layer between the actual DOM and the application state. It provides some render optimization techniques: while storing the entire DOM tree object in memory, it will compare the new state with the previous snapshot and do some efficient batch updates of UI. It was a real game changer back then, when JavaScript frameworks were pretty slow and complicated by its design. Virtual DOM revolutionized approach to DOM updates by taking all the headaches and doing it in a "smart" way.

But the main power of Virtual DOM is the ability to declaratively build dynamic interfaces without worrying about optimal ways of re-rendering. Modern SPA-frameworks implement the approach of building applications from a specific JSON that formally represents application’s state. As a result, there is no need to think about how it should make visual updates: framework does it on its own on whenever JSON changes, synchronizing the Virtual DOM with the real DOM. Automatic HTML updates on state changes is extremely useful, especially in large and complex front-end applications: updating the DOM manually would be a real uphill climb and would lengthen the whole development process. So this is where the Virtual DOM really shines.

With the growing popularity of frameworks like React and Vue, the myth began to spread that Virtual DOM is the ultimate silver bullet for lightning-fast rendering, as it improves real DOM re-renders somehow, but it is not true. The fact is that Virtual DOM is not faster than real DOM. As I mentioned above, this technology is just an abstraction that absorbs a lot of complicated rendering problems in large-scale front-end applications. In other words, Virtual DOM solves the change tracking problem rather than the performance problem. It means that if you need to build a simple small project or just a static landing page without a lot of updates, you wouldn’t benefit from using Virtual DOM. Moreover, using it will simply be overhead, as it will perform an unnecessary reconciliation process that implies the use of heavy diffing algorithm, resulting in computational complexity and increased memory usage, especially for large documents. In this article you can find some benchmark examples of Virtual DOM and its pros and cons compared to real DOM.

So if you need to handle just a limited number of DOM manipulations, then just do it manually – it is not a rocket science. In addition, there is a plenty of libraries and frameworks that reject the Virtual DOM approach and do some direct manipulations instead. The most popular by far are Svelte, Solid and LitHtml. But keep in mind that for really complex applications, there is no problem with using solutions that utilize Virtual DOM, as it will certainly save a lot of development time.

Subscribe to my RSS feed if you don't want to miss new posts.