4 ms·

One of the motivations for using a virtual DOM as opposed to updating the DOM directly is that DOM updates can be slow, with a minimum duration per change. Appl

by grzm 6y ago

One of the motivations for using a virtual DOM as opposed to updating the DOM directly is that DOM updates can be slow, with a minimum duration per change. Applying changes to a virtual DOM can be faster for individual changes, and then those changes can be batch-applied to the actual DOM, minimizing the number of changes to the DOM itself. For larger client applications this can be a win. Like all trade offs, the choice depends on the context.

sushshshsh 6y ago
Neato, so then much like an enterprise service bus (ew old term), there is a bus that comes at a rate of x hertz that events can be loaded onto, and the bus has a certain capacity for events. The busses then load events from the event queue and when it reaches the client, they're all rendered at once. Sounds cool. I guess this is what all of the componentDidMount and componentWillMount is used for?
ric2b 6y ago
If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. What V-DOM is trying to address is tracking what is changing in your application so that it can modify the DOM on your behalf, simplifying app development and reducing bugs, sort of like how a Garbage Collector manages memory for you and gives you similar benefits. Look at Svelte, it doesn't have a V-DOM and it smokes any V-DOM framework in terms of performance.
- littlecranky67 6y ago
  > If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. It uses a very smart algorithm to diff two vDOMs (previously rendered vs. newly rendered) and "calculates" a minimal* set of operations required to get the current DOM (=prev. rendered vDOM) into the new state of the DOM (=result from current vDOM render). Think in source code patches produced by tools like diff: A patch between two different code tree versions can fit just a few lines and is quickly applied against the tree, while shipping and writing the full tree is more expensive. *: ideally it would be minimal in a sense there is no smaller/faster representation, but thats of course not the case in real applications.

by grzm 6y ago

sushshshsh 6y ago

Neato, so then much like an enterprise service bus (ew old term), there is a bus that comes at a rate of x hertz that events can be loaded onto, and the bus has a certain capacity for events. The busses then load events from the event queue and when it reaches the client, they're all rendered at once. Sounds cool. I guess this is what all of the componentDidMount and componentWillMount is used for?

ric2b 6y ago

If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. What V-DOM is trying to address is tracking what is changing in your application so that it can modify the DOM on your behalf, simplifying app development and reducing bugs, sort of like how a Garbage Collector manages memory for you and gives you similar benefits. Look at Svelte, it doesn't have a V-DOM and it smokes any V-DOM framework in terms of performance.

littlecranky67 6y ago
> If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. It uses a very smart algorithm to diff two vDOMs (previously rendered vs. newly rendered) and "calculates" a minimal* set of operations required to get the current DOM (=prev. rendered vDOM) into the new state of the DOM (=result from current vDOM render). Think in source code patches produced by tools like diff: A patch between two different code tree versions can fit just a few lines and is quickly applied against the tree, while shipping and writing the full tree is more expensive. *: ideally it would be minimal in a sense there is no smaller/faster representation, but thats of course not the case in real applications.