That article doesn't quite support what you're claiming. The Vanilla JS implementation uses optimised DOM mutation techniques that are inspired by how the Virtual DOM libraries do things, but it doesn't re-implement a Virtual DOM. Yet it's faster than any of the Virtual DOM implementations its benchmarked against.
So the takeaway is that DOM mutation can be slower or faster depending on the techniques you use. Using a Virtual DOM library can help you improve performance, because these techniques are often baked in, but they don't intrinsically result from using a Virtual DOM: You could write a V-DOM library that didn't use them, and was slow, and you could write, for example, a static template library that did, and was fast.
In theory, a compiled, static template approach should be faster than V-DOM (or anything other than a set of totally bespoke and optimised vanilla JS functions for each app operation). Because while a compiled template does not have the turing-complete flexibility of something like JSX, it has the advantage of knowing in advance exactly which parts of the DOM can change and how, which eliminates the need to build and diff the Virtual DOM tree.
> In theory, a compiled, static template approach should be faster than V-DOM
Maybe faster in basic microbenchmarks. As soon as you start optimizing UI library for complex applications, there are many other optimization goals you should focus on, like the size of the generated code per component type, the amount of different code paths(increase probability that executed code is JITed), etc.
Virtual DOM solves many issues, it is not just diffing, it is also a lightweight component model, possibility to add lightweight synthetic events, single code path for creating/updating/destroying DOM nodes, the simplest algo that handles complex tree transformations, etc.
So the takeaway is that DOM mutation can be slower or faster depending on the techniques you use. Using a Virtual DOM library can help you improve performance, because these techniques are often baked in, but they don't intrinsically result from using a Virtual DOM: You could write a V-DOM library that didn't use them, and was slow, and you could write, for example, a static template library that did, and was fast.
In theory, a compiled, static template approach should be faster than V-DOM (or anything other than a set of totally bespoke and optimised vanilla JS functions for each app operation). Because while a compiled template does not have the turing-complete flexibility of something like JSX, it has the advantage of knowing in advance exactly which parts of the DOM can change and how, which eliminates the need to build and diff the Virtual DOM tree.