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.

> 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.

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.

>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.

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.

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.