Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: