Virtual DOM is pure overhead (2018)
I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced.Here's the gist of how folks would often update an element.  You'd subscribe to events on the root element of your component.  And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child elements that need updating - inspecting the DOM in various ways so as to determine the component's current state.If your component needed to affect components higher up, or sibling to the current instance - then your application is often doing a search of the DOM to find the nodes.. and yes if you architect things well then you could avoid a lot of these - but let's face it, front end developers weren't typically renown for their application architecture skills.In short - the DOM was often used to store state.  And this just isn't a very efficient approach.This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail.As far as I'm aware React and its VDOM approach was the framework that deserves the credit for changing the culture of how we thought about state management on the frontend.  That newer frameworks have been able to build upon this core insight - in ways that are even more efficient than the VDOM approach is great - but they should pay homage to that original insight and change in perspective React made possible.I feel this article and many of the comments here so far - fail to do that - and worse, seem to be  trying to present React's claim of the VDOM faster than the DOM as some kind of toddler mistake.