[peterhunt]

You get all of this for free with React.

DOM node reuse is perhaps the central theme of React so it's odd that you bring this up as a criticism (see https://www.youtube.com/watch?v=1OeXsL5mr4g)

Calculating the virtual DOM does come with some processing and GC overhead, yes. But any system that tracks changes for you (data binding) comes with overhead and React makes the right set of tradeoffs for real apps (since it is a function of how large your render output is, not your underlying data model). React has about a 70% edge in CPU time on Angular in the "long list" class of benchmarks (which drops to a mere 40% with the Object.observe() performance unicorn). And steady state memory usage is almost always better with a virtual DOM approach since again it only tracks what you actually render which is usually smaller than your data model (https://www.youtube.com/watch?v=h3KksH8gfcQ).

DOM coordination boils down to non-interleaving of reads and writes to the DOM. React manages the writes for you which happen in one go. Components have a well-defined lifecycle which is also batched and are only allowed to read from the DOM during specific points in the lifecycle, which are coordinated system-wide. So out of the box if you follow the guidelines you will thrash the DOM much less (see http://blog.atom.io/2014/07/02/moving-atom-to-react.html)

[syntern]

On the DOM reuse: could you help me out? I'm sure if I watch all the videos I may be able to figure it out, but I'd be interested in a trivial example. Let's assume I have the following structure (additional cells and rows are omitted for cleaner display, please assume we have 1000 rows and 20 cols):

    <div class="row">
      <div class="cell">
        <div class="align-left">
          Value.
        </div>
      </div>
    </div>

I want to reach the following:

    <div class="row">
      <div class="cell">
        <div class="align-center">
          Value B.
        </div>
      </div>
    </div>

What do I need to do in React that on updating the underlying data, only the innermost Element's class attribute and innerText would change, and the rest of the DOM will be kept intact?

[jameshart]

Can't respond to you on react (though my impression is that the entire point of virtual DOM diffing is to do exactly what you're after), but can you justify in some way your HTML markup using <div class="row"> and <div class="cell"> instead of <tr> and <td>?

[syntern]

As I am working on large tables, I may have a different goals than most UI developers are looking for. Diffing a huge structure is just a waste of time compared to not-diffing. Don't re-calculate things that you already know of, and in case of the table, you know pretty much upfront.

On the HTML markup, there are many valid reasons you may want to use non-TABLE based tables:

- it allows better rendering control for infinite scrolling (DOM reuse, re-positioning, detached view for sticky header and column)

- it allows you to have real (CSS style-able) row groups, or if your structure is hierarchical, it allows you a better control to create a treetable (reduced rendering time if you expand a node and insert a bunch of rows in the middle).

- it allows you to have multiple grid systems inside the table (e.g. a detail row may use up the entire row, and it may have its own table inside, which you'd like to synchronize across multiple detail rows). I guess this later benefit is just redressing the fact that you do need to implement an independent grid system anyway :)

[peterhunt]

It's automatic:

http://jsfiddle.net/bD68B/

I tried to make the example as minimal as possible, so I don't show off a lot of the features (i.e. state, event handling), but I did use JSX, an optional syntax extension for function calls.

[syntern]

Thank you, this seems to do it for the innerText. Would it be too hard to apply it to the class attribute too? (I've tried to just copy the {} binding, but it doesn't work)

[zenojevski]

Here, I gave it a try: http://jsfiddle.net/bD68B/1/

[danabramov]

There you go: http://jsfiddle.net/Q2KXu/1/

[syntern]

Thank you both! I now have a much better understanding on how React works. I need to update the related performance benchmarks, it would be interesting to see how they compare side-by-side on our use cases.

[danabramov]

Don't forget [PureRenderMixin][1], it can give a big perf boost when used in right places.

[1]: http://facebook.github.io/react/docs/pure-render-mixin.html