I don't think that's a great explanation of the concept of VDOM. For example, SolidJS looks a lot like the example given, and it also arguably returns an object that represents how the page looks, but it didn't use a virtual DOM under the hood.

I think it's easier to think of virtual DOM implementations as doing two things: (1) describing the desired state of the DOM in some sort of structure, and then (2) diffing that structure against the actual DOM in order to make the changes. The key part is that the virtual DOM implementation does the diffing itself in order to make the changes itself.

This is similar to your example, in that you have generated the desired tree and are rendering it in the right place. However, it is different, because the browser will not do a fine-grained diff of all the elements, it's just going to replace them with the new elements that you've given it. This works fairly well if you're trying to replace a large chunk of elements with a new set of elements, but it has problems if you just want to make smaller modifications.

For example, consider some JSX for an arbitrary framework that looks something like this:

    function MyInput({ isGreen }) {
        return <input class={isGreen && "text-green"} />
    }

When `isGreen` changes, we want to update the current value of the DOM with the new version of MyInput, which should just be the same thing with the class changed. The naive (although often simplest and most practical) solution would be to just replace the contents of the element with the return value of MyInput - i.e. replace the input with a new copy, just with the class name changed. The problem comes when a person is typing into the input - if we replace it completely, the use will lose everything they've already written.

The VDOM solution is, as I said, to (1) generate, but then (2) to diff. So if the current state is an input with a "text-green" class, and the desired state is an input without this class, it would work recursively: First, is there an element? Second, does the element have the right tag name? Third, for each attribute on the two elements, do they have the same values? Etc. And every time there's a change, it will make the smallest change possible to ensure the current state becomes the same as the desired state. Here, that means removing the class name, but leaving the rest of the input as it is (i.e. with any input from the user left alone).

The third option here is what frameworks like Svelte and SolidJS do: they skip the part of the process where you generate a new desired DOM, and jump straight to the diffing. That is to say, when you create a component, inside that component will be event listeners for each part of the component that needs to change (and only those parts). This listen to changes in the props and state and then change only those parts of the DOM that need to change. That way, you don't need to go through the entire DOM, iterating through all those nodes that stayed the same just to find the class that needs to be updated. Instead, you just directly update the class.

For some reason I thought the virtual DOM was a native feature of the browser, in the form of the DocumentFragment class, and had nothing to do with diffing. But you are saying that it's just a concept, and is implemented by frameworks such as React, and involves the two steps of generating and diffing.

I'll still ask why. Is it just something that React needs to do?

Using some sort of VDOM is still pretty standard in most frameworks, it's definitely not just React doing this. The motivation is generally an attempt to model an application as a function `(state) => DOM`. This is probably similar to the `renderMyModel` function in your example: take state in, and return what the document should look like given this state.

The problem with this is that if you rerendering the entire DOM every time the user interacts with the page at all (and therefore changes the state) then you will run into issues. The main one of these is that the DOM itself has state, such as event listeners, or the contents of input fields. We don't want to throw this state away as well, instead we want to sing m synchronise it with the state that _should_ be. I mean, in your example, you wouldn't run the `replaceElement` function every time the user presses a key or moves their mouse, right?

VDOM is basically the solution. It can run every time a mouse is moved, because instead of just replacing everything, it replaces only the things that have changed. Assuming the input hasn't been swapped out for a different element, then it can stay. It might gain or lose a class, or the value attribute might get updated, but the element itself stays were it is.

>rerendering the entire DOM

No, just rerendering the viewport that was affected by the model. I have no need to re-render headers, footers, menus, etc.

>DOM itself has state

No. The viewport has no state. It's just a transformation on the model. And I don't place any event listeners in my viewport DOM.

> every time the user presses a key or moves their mouse

Of course not - and I wouldn't expect an application to be updating the model on key presses.