VDOM on the Server - Problems?

Why do you want to handle user input live on the server? The only common case I can see using something like that would be live search results.

What about this:

C: {ref: "xz723", name: "My Name"}
C: {ref: "v44ns", name: "Another Name"}
S: {ref: "xz723", domNode({name: "My Name"})}
C: I’m ignoring that, my ref is "v44ns"

Or even

C: I’m ignoring that, did you see what I just sent you? {ref: "v44ns", name: "Another Name"}

I can think of other cases, such as realtime validation of form parameters, password strength checking, etc.

But these limitations apply even without “realtime” handling of keystrokes. Just suppose you type the name, press a save button and then type another name before you receive the reply from the server.

The input componenet will still revert to the previous state for a while (and then revert back)

This really sounds more like something RxJS is used for:

• Whenever input changes, reset client side UI rendering to reflect that data has not been validated.
• As input state changes, dispatch validation requests to the server.
• Upon validation response the client verifies that the validated data matches the current input data (client based correlation id would be faster) - and only when it matches, the UI renders client side with validation errors or success.

Ultimately a server-based VDOM is just way too chatty - too many, too finely grained updates need to be exchanged between the server and browser.

That might actually work. It sounds like a very limited form of Operational Transformation that might be useful in practice

Drab is already halfway to that, it creates a pre-processed virtual dom for fast updates later. ^.^;

However, as for the latency Drab generally just disables what is being waited on until it completes (configurable of course).

Drab seems to use “mutation watchers” which try very hard to rerender only the UI parts that depend on values that have changed.

This is very different from a VDOM in reactjs or the elm architecture in which the engine renders a new dom and diffs t against the previous one.

I don’t think you can get from Drab to a VDOM incrementally, because those are very different concepts.

Those watchers are how a vdom diff works anyway (it’s certainly how my super-fast-yet-not-optimized bucklescript-tea vdom diff’s anyway). There are lots of ways to implement vdom’s, React’s broken way is not the only way. ^.^

I think that the problem here is latency alone, not chatinness. You can be as chatty as you want as long as you can output a DOM diff between two user events (in the limit, between 2 keystrokes). That guarantees that you’l never rever input components to the last update (because you’ll be setting the component’s input yo the value it already has).

That’s doable with local Javascript, but it’s not doable over the network.

Does your approach with mutation watchers work with general render functions?