We can replace mentally any or on the page with . When the application state (fuzzy term but still) changes we request these content generating functions to re-execute.
The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use:
function onDataModelChange(model) {
element.html = provideHtmlRenderingOf(model);
}
can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW.The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc.
So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about based editors, their content cannot be reactive in principle.
That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.