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.
[1] http://www.umut-acar.org/self-adjusting-computation
Assume you have a function f that takes the model data as input and computes the DOM as output:
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.