DEV Community

Cover image for Why is the Virtual DOM So Fast?

Why is the Virtual DOM So Fast?

Domagoj Vidovic on July 07, 2021

When you start learning about the frontend world, you’ll almost immediately stumble across the term “Virtual DOM”. Most of the popular frontend fr...
Collapse
 
przemek profile image
Przemyslaw Michalak

I think the future is going towards much different solution:
javascript.plainenglish.io/javascr...

Collapse
 
jonrandy profile image
Jon Randy 🎖️

RiotJS came 6th overall - nice! I've always thought it was great - and ridiculously underused

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited

I'm not pushing Svelte (have never used it) - but the virtual DOM isn't necessarily the best or fastest way to go...

svelte.dev/blog/virtual-dom-is-pur...

Collapse
 
joelbonetr profile image
JoelBonetR 🥇

Svelte does not use virtual DOM and performs better depending on the scenario, the needs, the implementation of the front-end framework and the implementation of the code and of course, the machines running that

Collapse
 
valeriavg profile image
Valeria

Let's imagine you're a painter and the client asks you to fix just one thing, but you decide to redraw the whole painting instead and then praise Photoshop for allowing you to do it digitally and save you canvas and materials, that otherwise would be wasted.

VDOM is made to avoid full render on a partial change. It can never be faster than a manual update to each particular DOM object in question.

Collapse
 
lilithkarapetyan profile image
Lilit Karapetyan

Nice one!
Everything about the VDOM was explained very understandable and clear. Thank you for the additional information about the browser rendering. I've read several different articles, which told, that the heaviest part is the painting process, but they did not explain why the content painting is so expansive. The information about the layout stage and the painting stage were minor details, which filled the gaps.
I think it would be better to compare the performance of a VDOM-based application to the performance of the same application written in a framework/library using another optimization technique.
Still, it was a very informative and interesting article!

Collapse
 
akramnarejo profile image
Akram Narejo

and your feedback has differentiated the article from others. nice job Lilit.

Collapse
 
oenonono profile image
Junk

Nicely written and clear.

It seems to me that fast is marketing language, not technical. And that it was fast compared to some specific implementations of bindings that predated it in a context with similar assumptions about SPA architecture, but that it is not fast in absolute terms.

Because there are a lot of caveats. What about the large amount of JS required up front and how that trades away startup performance? What about the need for SSR and the uncanny valley of hydration? What about the loss of HTML's historically demonstrated ability to stream and gracefully degrade? What about the poor performance of virtual DOM based libraries on mobile devices? Etc.

But that'd make for a much longer and less satisfying article.

Collapse
 
aidenybai profile image
Aiden Bai

I would love to see maybe a section at the end discussing the nuance of Virtual DOM, for example, discussing how imperative DOM manipulations will be faster and compiled js lib performances

Collapse
 
jjablonskiit profile image
Jakub Jabłoński

Great 👌

Collapse
 
domagojvidovic profile image
Domagoj Vidovic

Thanks mate ✨

Collapse
 
akramnarejo profile image
Akram Narejo

thanks for explaining it Domagoj.

Collapse
 
ananddevspace profile image
Anand

Thank you,Nice Explanation 👏 👏

Collapse
 
132 profile image
Yisar

In fact, on the mobile side, the real performance bottleneck is the WebView initialization time, and the HTTP resource loading time. JS is cheap

Collapse
 
edmundophinx profile image
Edmundo Barbieri, Muni.

Thanks mate!