IIRC the performance gain is when doing things like updating the state of a deep component tree, where react and others diff on the vdom to see what elements need to be re-rendered and then only so actual dom manipulation on those, rather than clear and re-render the entire tree.

I’ll be honest, though, it feels to me like a solution to a hard problem you inflict on yourself by first committing to have the giant component tree rather than questioning if that was a great idea.

I think he's comparing VDOM to the equivalent imperative instructions, which !== re-rendering the entire tree.

For example we want to turn the prev tree into the next tree:

Prev:

  <ul>
    <li>1</li>
  </ul>

Next:

  <ul>
    <li>1</li>
    <li>2</li>
  </ul>

A VDOM would have a representation of prev and next in objects, diff them, and then decide to do something like

  parent.appendChild(makeLiWithText("2"))

OP is saying that this is less efficient than just manually executing the above line. Obviously, it's less efficient because the latter solution skips the entire diffing process.

I do think OP is missing the point of VDOMs. "Figuring out" the resulting imperative instructions for a given prev -> next is not easy (the above example, however, it trivial), and is very error prone, which is why the VDOM diffing solution is motivated in the first place.

> I think he's comparing VDOM to the equivalent imperative instructions, which !== re-rendering the entire tree.

You don't have to have tons of handcoded input handling or tree merging code. As I said in another post, the approach with some structured getters and setters was known since time immemorial. S.js, I think, is the best modern iteration of the approach. There are a lot of different ways of handling that, just google.

> "Figuring out" the resulting imperative instructions for a given prev -> next is not easy (the above example, however, it trivial), and is very error prone, which is why the VDOM diffing solution is motivated in the first place.

Yes, you very much get that. For that reason, when someone is faced with handling frequent and complex page structure manipulation, he is better to apply some actual computer science knowledge, and algorithmics to the task, than to use half-baked solutions. This is exactly because the gain from doing things properly in such case is great.

From utility standpoint, VDOM has its use, but its advertisement as a somehow superior and more performant approach is a disingenuous.

Yes, you do not need to re-render the whole element tree, but you do not need that "Virtual DOM" to do that. It's truly is an "anti-solution" for the problem.

Even back in "medieval" era when YUI was the king, the practice of making getter-setter pairs with direct control over DOM elements was recognised as a preferred practice over any kind of state machine controlled page re-rendering system.

There of course was Angular.js - the prime target for React authors, against which all their claims held true.

You have to have some ideas of what the state was before the change, and what changes need to be done to transfer states. In complex UIs, writing custom update logic for every change results in an unmaintainable mess and a large payload to the client.

Yes, but proper, technically superior ways for "data binding" and templating were around since IE6 era, just back then people were not concerned much with doing things properly with javascript as the universal presumption was "if it uses JS it will be slow invariably of amount of efforts put into it."

That’s not the case with RE:DOM, since you have a single update function to make pure updates.

I usually create a requestAnimationFrame debounce to have just a single render per animation frame.

His point is that writing the single update function becomes complex when you have lots of changes to apply.

The beauty is that you know exactly what’s happening and when.

Debugging is also way easier without long stack traces.

There’s pros and cons in everything.

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.

Personally I was quite surprised by the good performance of React 16 + Preact in the benchmarks. It's not much slower and does all the "update" logic for you.

Keep in mind, too, React handles MANY edge cases for scenarios like keeping scroll position on update, or animations.

Yeah it’s become way faster that’s true! The thing I have with React (and similar) still is that there’s so much black magic happening. I like to be more in control what’s happening and when.

But usually the bottleneck with React apps are state managing libraries, like Redux etc plus all the other bells and whistles.

Yes, after many years, they polished it to the limit, and browsers themselves got faster. That made the slowdown much less noticeable.

I have only one upvote to give you but thank you for your comment. I am not very familiar with the Js world and it's riddled with vocal minority of not-so-knowledgeable people and I had no clue that the vdom fad wasn't actually reasonable.