3 ms·

If manipulating the DOM directly is so much faster than using a virtual DOM, then why do libraries like React or Ember use a virtual DOM in the first place? I h

by xtagon 8y ago

If manipulating the DOM directly is so much faster than using a virtual DOM, then why do libraries like React or Ember use a virtual DOM in the first place? I honestly though it was for speed.

gpmcadam 8y ago
It depends what you mean by "faster". In some cases you'll be better off with something lighter and accessing the DOM directly. If you need to do something at scale, then you may choose React. The benefit here isn't from just something as simple as changing the items in a list or the text in a header, but when you need to have large amounts of state in an app that is represented by a complex DOM tree. The benefits of React here are that the virtual DOM can prevent unnecessary updates to the rest of the tree when your state change should only affect a nested element, for example.
- xtagon 8y ago
  That makes sense. Thanks for explaining :-)
localvoid 8y ago
Full disclosure: I wrote a vdom library ivi[1]. Being fast is not just about micro updates, I think that most vdom authors don't care too much about micro updates performance because it isn't a bottleneck. For example, Virtual DOM with a powerful composition model can significantly reduce code size because composition gives you code reusability, and virtual dom is one of the most compact output formats to render/update DOM. 1. https://github.com/localvoid/ivi https://github.com/localvoid/ivi
ng12 8y ago
The problem is it's very easy to write non-performant JS code if you're adding/removing/modifying lots of DOM elements, and attempting to do it performantly by-hand tends to lead to a lot of bugs. VDOM isn't performant in the sense that it modifies the DOM faster but in the sense that it allows you to write code that wouldn't be performant and have it execute efficiently. In React you worry about your data flow and component structure without needing to worry about DOM performance.

by xtagon 8y ago

If manipulating the DOM directly is so much faster than using a virtual DOM, then why do libraries like React or Ember use a virtual DOM in the first place? I honestly though it was for speed.

gpmcadam 8y ago

It depends what you mean by "faster". In some cases you'll be better off with something lighter and accessing the DOM directly. If you need to do something at scale, then you may choose React. The benefit here isn't from just something as simple as changing the items in a list or the text in a header, but when you need to have large amounts of state in an app that is represented by a complex DOM tree. The benefits of React here are that the virtual DOM can prevent unnecessary updates to the rest of the tree when your state change should only affect a nested element, for example.

xtagon 8y ago
That makes sense. Thanks for explaining :-)

localvoid 8y ago

Full disclosure: I wrote a vdom library ivi[1]. Being fast is not just about micro updates, I think that most vdom authors don't care too much about micro updates performance because it isn't a bottleneck. For example, Virtual DOM with a powerful composition model can significantly reduce code size because composition gives you code reusability, and virtual dom is one of the most compact output formats to render/update DOM. 1. https://github.com/localvoid/ivi https://github.com/localvoid/ivi

ng12 8y ago

The problem is it's very easy to write non-performant JS code if you're adding/removing/modifying lots of DOM elements, and attempting to do it performantly by-hand tends to lead to a lot of bugs. VDOM isn't performant in the sense that it modifies the DOM faster but in the sense that it allows you to write code that wouldn't be performant and have it execute efficiently. In React you worry about your data flow and component structure without needing to worry about DOM performance.