There was no notion of a virtual dom in the ie6 era that I can remember. Unless Prototype (the precursor to jquery) used one and I just wasn’t aware of it. I believe the libraries of that time either directly extended the dom or wrapped individual elements, but did not maintain anything resembling virtual doms as we know them now.
I wanted to say that manipulating DOM objects without tricky state machine that was supposed to store the element tree structure as data in JS and subsequently recreating it from it was always faster than with it.
Even in the often brought forward case "when a lot of changes to DOM don't translate to changes in markup," like demonically complex template merges, never seen in real life, that VDOM proponents like to throw into benchmarks, VDOM often lost because they were trying to do browser's job when they really shouldn't.
Browsers already used a lot of very similar logic on the inside when DOM 3.0 was being popularised, and it's only natural that VDOM was losing out by trying redoing what browsers were already doing.
> manipulating DOM objects without tricky state machine ... was always faster than with it.
You miss the point of VDOMs. VDOMs aren't so much about performance as they are about ease of development and automatically maintaining tree consistency. No one disputes the fact that creating templates and diffing them against the DOM adds overhead compared to writing out the equivalent instructions manually. The point is that nobody wants to write out imperative spaghetti for complex applications.
> The point is that nobody wants to write out imperative spaghetti for complex applications.
You really don't have to, you just have to walk out of that "wood of popular notions." There are libs to handle functionality of any part of a modern MVC app: reactivity, input handling, declarative components, templating... that don't even making you think of manually manipulating the DOM tree.
