HN Theater @HNTheaterMonth

Adding a late comment to appreciate the MVVM synopsis in your blog post. The pain of tracking lots of callbacks and cascading updates is a lot of what Pete Hunt was talking about in Be Predictable, Not Correct [0], but there's not a lot of discussion applying that analysis to MVVM as for other forms of MV*. I find it's a real concern in WPF apps with much of any complexity.

[0] https://www.youtube.com/watch?v=h3KksH8gfcQ

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?

⬐ 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)

⬐ 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

⬐ zenojevski

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

⬐ 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 :)

I had to cut the Knockout-specific slides, but I do cover this topic in depth here: https://www.youtube.com/watch?v=h3KksH8gfcQ

tl;dr it's about expressiveness

⬐ paultannenbaum

Very interesting talk. Thank you for sharing

⬐ ufo

I found the presentation really interesting.If I had to give a slightly larger TLDR the two main points I got from it were

1) In a virtual DOM system your view code is a black box, while in an observable-based system you need a way to specify all the data bindings. This means that virtual DOM systems can use usual Javascript abstractions (functions, varuiables, etc) where observable systems often need custom DSLs (for templating, data-binding, etc). Additionally, data binding can be tricky to get right when it gets more complicated, for example, if you have a sorted list of items it needs a way to know that should be rerendered when the inner properties change.

2) Performance: in a observable-based system, the memory and CPU costs are related to the size of the model while in a virtual DOM system the costs are related to the size of the view. This can be a performance gain for the virtual DOM if you have a big model but use windowing to display only part of it. Also, the O(n) cost on the size of the view is usually not a problem since views tend to be small enough that that fits inside one repaint frame.

⬐ baddox

How does JSX not count as templates with data bindings?

⬐ peterhunt

JSX is just syntax for instantiating data structures. Nothing more.

⬐ ufo

In that context, data binding means that you observe the model and set up a data flow so that you only need to update the specific parts of the view when the model changes. JSX doesn't do that as all it does is render the view. You need to detect and trigger repaints separately and when that happens it will blindly redraw everything instead of just updating the relevant DOM nodes.

Also, JSX is a relatively lightweight wrapper that uses native JS constructs for looping and subroutines. This is in contrast to things like Angular where the templating system has its own way of scoping variables, abstracting out subtemplates, looping over arrays, doing conditionals, etc. Angular must use these special DSLs and abstraction mechanisms because there is no way to do full data binding with just plain old Javascript code.