Hacker News Reader

Comment by bigmanwalter | Hacker News Reader

The React documentation says it so it has to be true. DOM slow, VDOM fast. Facebook is out there buying developer mindshare.

View on HN

We don't claim that in React documentation. React can't be faster than the same DOM mutations written by hand because by definition it has to do more work.

We do think it helps to create maintainable apps though, and it is fast enough for practical use cases despite its immutable design. That's why we use it at Facebook.

I just haven't been able to figure out what, exactly, it is about manual DOM mutations that makes an app unmaintainable. As long as your code is organized and modular, it's always been easy enough for me to navigate through and maintain a non-React codebase.

Probably finding the right place of the dom to change and keeping track of what to change. React basically says "make it like this" and takes care of a lot of things.

jQuery code is well known to be hard to maintain when it changes things based on element-types, classes and id's nested in each other.

It's quite simple to handle that situation with jQuery and modules. If many parts of you code need to make a change to the DOM in the same place, you wrap the DOM changing in a module.

  var widget = require('./widget');
  widget.foo('bar');

And the widget handles the jQuery'ing for you.

  module.exports = {
    foo: function(s) { $('.widget').text(s) }
  }

Only:

- it breaks immediately if there is more than one '.widget' on the page

- your app will get out-of-sync DOM updates because different parts will flush changes to the DOM at different times (React is DOM = f(state, time), so if multiple changes happen in f, they all be flushed to DOM in one go)

I found these things hard:

* Inconsistencies or duplicated code between initial render and updates.

* Having to write code for N^2 transitions between N valid states instead of N valid states themselves.

* Harder to ensure DOM operation order across different parts of the codebase doesn’t produce jank.

Sure, this is all possible to solve, but in my experience I just ended up with a crappy version of React.

Seconded on all counts. We also ended up independently implementing a really simplistic and in many ways broken version of React for these reasons and many others.

In my experience it's the needed complexity added by bookkeeping and the coupling that requires to do rendering/updates and data binding using manual DOM manipulations in a performant way, especially in larger scale apps. You can easily write maintainable and simple applications that manipulate the DOM directly if you don't care about performance, or in some cases correctness, and you'll quickly do worse than React would, from what I've seen.

Reply on news.ycombinator.com