I’ve been looking at the possibility of implementing a server-side VDOM (Virtual Dom, like Reactjs, Vuejs, Snabbdom and onthers). The problem I see with this is the high latency of the updates, and the way it interacts with input components. Suppose you have a VDOM that returns the following (using vue-style templates):

Enter your name: <input v-model="name"></input>
<br/>
<span>Hello {{ name }}!</span>

The UI should be updated as the user types (probably debounding events, but that doesn’t change the main point).

Suppose the user types a “My Name”. The event is sent to the server, which sends the minimum delta so that the browser’s DOM is changed. But suppose now that before receiving the update, the user types “Another Name”. This can happen because latency between client and server can be arbitrarily high…

You’ll have something like this:

1. User requests a page. The server sends a DOM with name = ""
2. User types “My name”. The server receives an event. The server sends a new DOM with name = "My Name"
3. The user types “Another Name”
4. The user receives a new DOM with name = "My Name", which overwrites the text in the input component. This is a very surprising UI change
5. The server receives name = "Another Name"
6. The UI changes back to the previous version.

I don’t think how one can avoid this. There is a serious mismatch that will keep the client and server permanently out of sync. Althout I’ve often felt that a VDOM was superior to the approach taken by Drab (which has the concept of living assigns, and instead of re-rendering everything and diffing the result updates parts of templates that correspond to specific mutations), now I’m not so sure, because of the way the network latency messes with the input components’ updates…

I’m not aware of any widely used server-side VDOM, so I don’t know if anyone has managed to find a way around this limitation.