Touching the DOM is by far the biggest bottleneck in performance. Of course for some arbitrary discrete task, hand coded DOM manipulation code is always going to be faster than a layer of abstraction on top of it. But the strength of virtual dom is that a single piece of code can handle insertions, deletions, sorts, splices and pretty much any data contortion you can throw at it without increasing code debt. Managing all of those w/ only the DOM API (or jQuery) as an application grows is difficult, and it's one of the main reasons why frameworks exist in the first place.

> Touching the DOM is by far the biggest bottleneck in performance

My point was simply that this devolves back to Amdahl's law: the only way that React overhead + the DOM can be faster than the DOM alone is when the pure-DOM code is doing too much work. It's possible that React makes the code so much easier to maintain that you write better algorithms but that has very little to do with the virtualdom rather than the strong push towards better structure.

There's the fact that dom changes related to a given set of events can be made as part of the same changes to the DOM as a whole... which can reduce parts of the render time overall.

However, depending on your needs, a stream of changes may behave differently in different use cases... to me React simply represents in my mind a better way to manage components and rendering logic, combined with something like flux for data and event flows.

That productivity gain is, in my mind, the better reason to use React. Browser performance characteristics change and most of the time you're not pushing the limits but ugly code is forever.