> The only option is to run the code above again, in its entirety

Not at all. The reactive pattern typically boils down to something like this:

    el = document.createTextNode(initialValue);
    parent.appendChild(el);
    reactiveValue.onchange(v => {
      el.nodeValue = v;
    })

Ironically, in this specific example, vdom libs typically do this when possible:

    parent.textContent = v

which does in fact replace the underlying text node, but they do so for the sake of performance

Yes, you can code like that, but ultimately that block will be contained inside a closure that will get triggered by some change. Of course, unless you are very careful.

The element creation part will be triggered if a creation is required. It won't be triggered by a prop update, for instance.

In the following example, I change the button id on click. It's still the same button element after the change:

https://jsfiddle.net/dwn36aw4/8/

But it's very difficult to prevent unnecessary dependencies from triggering in all cases. Consider a map (dict) with some values. Some outer code depends on the map. This code builds some DOM elements and sets values based on the values in the map. Now, if the map changes, all the elements will be recreated, even if effectively some irrelevant part of the map changed. Of course you can prevent this from happening by doing smart diffing on the map, but now you've effectively moved the problem from dom-diffing to map-diffing.

I wrote about that (and the drawbacks and alternative takes) here: https://news.ycombinator.com/item?id=16540223 but yes, in a nutshell, "move the problem from dom-diffing to map-diffing" is basically what a reactive system is supposed to be taking care of.

You're absolutely right that reactive systems are not trivial to implement (let alone implement well), but inefficient DOM recreation under these systems is a symptom of poor granularity in the reactive layer (which may be a problem with the reactivity library just as well as it could be poor usage of its API), rather than a limitation of the rendering library itself.

Ok, that makes sense.

I'm also worried about debugging accidental dependency triggers. Imagine that suddenly the scroll-state of some div is reset; how do you determine which dependency caused the DOM element to be recreated? With a vdom you avoid the whole problem.

> how do you determine which dependency caused the DOM element to be recreated

Normally, I would toss in a throw and look at the stack trace. But yes, the stack trace gets noisy as hell.

what you discribe is basically what https://github.com/google/incremental-dom is all about and in certain cases it probably is as fast as vdom and also less memory heavy.