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.