The idea behind a virtual DOM is clear: Build an in-memory representation of the dom and just apply the differences to the "real" DOM. This makes perfect sense on a machine, that is relatively slow. But is this still true today?
I entered the scene relatively late, just a few years ago. Before I was using compiled languages like C++, which are amazingly fast - most of the time. But - many people use mobile devices today, and a web browser may serve well to make your application platform independent. So, we checked out what is possible today.
Another amazing part of the browser performance was the increadible well performing double buffering of screen content: Even rebuilding the greatest part of the screen did not even cause a flickering of the screen. It seems, the guys at google did an exceptional good job designing the chromium engine (Which is the same for other current browsers like firefox or opera too). In any case: there are strong tools in modern browser to hide unnecessary screen updates and present a smooth experience, even if the programming was not that good.
We did a lot of direct DOM programming and where always happy with the performance: It just seems that the world has changed today.
There is a simple question: Maybe it was right in 2012 to create a virtual DOM. But times have changed. A virtual DOM means: additional calculations are to be performed. Specially the diffing may cause tremendous load. And we know: There is a second machine behind (implemented in the browser), that also performs similary well to hide unnecessary screen updates.
My questions is: Do we still need a virtual DOM? IF the browser is hiding unwanted screen updates, what happens with the virtual DOM? Does it just create additional processor load. Is it possible that both systems may interfere in and unexpected way that makes things even worse?