Hacker News Reader

Comment by d0m | Hacker News Reader

It's missing the most important React feature (Virtual-DOM diff.).

More specifically, he's manually adding and keeping track of all DOM elements. Once elements need to be updated, he would need to go back in the DOM and manually add/remove/change elements.. welcome back to the jquery messy world. Whereas with React, the render function doesn't change because it gets smartly rerendered.

Also, as far as I'm concerned, jsx is a big part of what I like about React. Basically, being able to add html from javascript instead of using all kind of hacks.

View on HN

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.

Reply on news.ycombinator.com