3 ms·

Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative man

Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. Virtual-DOM diffing was created to try to emulate the effect of refreshing the entire page every time state changes like we did with stateless web applications but do it in a relatively performant way.

Kwastie 11y ago
> manually updating the DOM is as optimized as you can possibly be. Optimized in the sense that it uses less memory and cpu. But the code isn't optimized for humans to reason about (not to mention changing it.) React was never about performance, it's about maintainability, readability and reasonability. For me readable and maintainable code is (almost always) more important than fast code.
- d0m 11y ago
  On big project, it becomes impossible to optimize the DOM interaction yourself, so you start to do very inefficient operations for sanity's sake. React on the other hand abstract that for you. I had a project with Angular where one page was really slow. I re-implemented it with backbone / jquery, it was a bit faster but really hard to read and maintain. With React, the code was simpler AND faster, which I was really surprised about.
localvoid 11y ago
>Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. The actual problem is how to efficiently traverse/modify DOM structure, in the end you'll just reimplement virtual dom.
- marknutter 11y ago
  Well, no, not really. You will only replace/update the elements that you need to which is pretty much what vdom boils down to. It's just tedious, is all.
  - localvoid 11y ago
    In a real application, you'll need to deal with moving elements, document shape will be changing, etc. Trying to solve this cases is the most complicated part of vdom libraries. If you try to do naive replace/update, it will be significantly slower.

Kwastie 11y ago

> manually updating the DOM is as optimized as you can possibly be. Optimized in the sense that it uses less memory and cpu. But the code isn't optimized for humans to reason about (not to mention changing it.) React was never about performance, it's about maintainability, readability and reasonability. For me readable and maintainable code is (almost always) more important than fast code.

d0m 11y ago
On big project, it becomes impossible to optimize the DOM interaction yourself, so you start to do very inefficient operations for sanity's sake. React on the other hand abstract that for you. I had a project with Angular where one page was really slow. I re-implemented it with backbone / jquery, it was a bit faster but really hard to read and maintain. With React, the code was simpler AND faster, which I was really surprised about.

localvoid 11y ago

>Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. The actual problem is how to efficiently traverse/modify DOM structure, in the end you'll just reimplement virtual dom.

marknutter 11y ago
Well, no, not really. You will only replace/update the elements that you need to which is pretty much what vdom boils down to. It's just tedious, is all.
- localvoid 11y ago
  In a real application, you'll need to deal with moving elements, document shape will be changing, etc. Trying to solve this cases is the most complicated part of vdom libraries. If you try to do naive replace/update, it will be significantly slower.