Am I the only one who doesn't like React? It is an ad hoc hacky solution to the view update problem. Diffing DOM trees is not just done for efficiency, but also for correctness. If you have a textbox somewhere with the cursor in it, and you update some other part of the DOM because of a network event, you want to retain that cursor position. If you just blindly put a whole new DOM on the page then the user would be confused because the focus on the textbox and the cursor position would be lost. With DOM diffing you have to keep in mind how exactly the diffing is performed because it will have actual visible effects on the user interface when user interface elements have state that is not represented in the model. You just have to hope that Reacts diffing gives you the behavior that you want. And what about interface elements that have internal state but which are implemented in Javascript rather than in the browser itself? React doesn't do anything to solve the view update problem for them. Seems to me that we need a more principled solution that tackles the problem head on, instead of a hack that happens to do the right thing most of the time.
React's diff algorithm is completely deterministic. For form inputs and other components which have their own state, it's recommended to put a `key` attribute on each one so that React understands what you meant if you reorder elements in a list: http://facebook.github.io/react/docs/multiple-components.htm.... Idiomatic React code usually has very little state except at the top of the tree so this is rarely a problem.
Right, but why do diffing in the first place? First generating a whole new tree and then computing the diff is (1) wasteful (2) leads to problems because you need to find the correspondence between nodes to preserve state. If you do something like Self-Adjusting Computation [1], you can still write your program as if you are generating the DOM as a function of your data, but the machinery under the hood can compute the diffs directly by keeping track of the dependency graph and the correspondence between the old and the new is fully automatic.
Assume you have a function f that takes the model data as input and computes the DOM as output:
dom = f(model)
If we now do an update to some model data, that has some effect on the DOM. When executing f for the first time, the machinery of self-adjusting computation records the dependencies of the different dom elements on data in the model. If some part of the model is updated it can propagate the changes along those dependencies to compute the parts of the dom that change as a result.
David from Meteor here. We're moving away from DOM diffing for essentially the reasons you describe. If you assume that views are written in a template language, which is the norm, then diffing is usually unnecessary. I'd never heard of self-adjusting computation, but it sounds a lot like what Meteor does! Thanks for the link.
All that said, I think React's model is great, and performance is actually fine. The React guys are not naive about browser performance; they've thought way harder about it (and tested more) than the commenters here seem to realize. The diffing is performed in pure JavaScript and is very fast. Creating a framework for declarative views in JavaScript is a pretty tough problem, and diffing is a major tool in the toolkit of ways to make it possible, the same way treating certain objects as immutable or storing JSON in your database are tools that enable certain styles of programming.
What pulled Meteor away from diffing as a central paradigm was the desire to stay closer to today's web development techniques and make things simpler for the developer. We wanted to provide the ultimate automagical version of templates and jQuery rather than something new you have to understand. When you have templates, you don't have to lean on diffing as much. When you have jQuery in play, you make fewer assumptions about owning the DOM (in React, every DOM element is backed by a component).
In the long term, the jQuery part will fall away as declarative templates and components do the heavy lifting and the DOM is seen as less hostile (with IE8 retiring, for example).
Unfortunately I don't have time to read the complete thesis, but I skimmed it a bit. My general impression is that this sets up a data dependency graph and uses that to inform the engine of which DOM updates to do, right? Isn't this what Knockout does implicitly and Ember does explicitly? If so, our observation of real-world workloads is that the overhead of maintaining this graph negates the wasteful work, since the wasteful work is actually quite cheap and can be constrained by hints to the system.
Input fields are typical DOM elements and are of course not overlooked. It's rather trivial to implement your own <MyTextArea /> component which keeps track of cursor position, etc. In fact, that's actually what React does. The <textarea /> component you use is actually a thin wrapper on top of the actual textarea (don't forget that the DOM is virtual in React so you get the luxury of these transparent wrappers).
This has serious implications. For one, the browser inconsistencies are taken care of for you, both for DOM elements and for events (which are also virtual). You effectively get cross-browser DOM tags/attributes/events/etc. without ever knowing it.
