I know this is obvious, but I'll say it anyway benchmark is a bit pointless against hypothetical alternative, it should be benchmarked against frameworks trying to solve same problem like WebComponents (Polymer), Angular or other frameworks.
I know that React’s performance has been compared to that of other frameworks, like Angular. What I wanted to do was my own test of it against plain old vanilla JavaScript…The docs claim that JavaScript is fast, and it’s meddling with the DOM that’s slow. So for that to be true we should be largely able to switch out React with something else and see pretty similar performance characteristics.
IOW, it's a common assumption that React has minimal overhead for DOM manipulation, and this benchmark suggests that it rapidly becomes performance constrained on relatively small DOM trees, especially on mobile.
I don't know if this is accurate or not (I suspect there's something a bit off, because the numbers don't look realistic to me) but it's worth looking at anyway!
Comparing it to vanilla JS is the pointless part to me, that's like comparing a appending a list, and diff algorithms together, with complicated way to say it.
Of course it is a lot of work to diff two DOM trees, but the general impression on React was that the DOM is soo unbelievably slow that it will still be much faster to do the diffing (which i never understood, technically, but what the heck, FB engineers are wizards!). At least, that was my impression i got from the React announcements. And i don't even code JS nowadays, so i couldn't care less if you prefer React or Ext or write everything as Silverlight plugin :P
Nevertheless, if you ignore the code complexity, i am fairly certain you can write JS code to update something without needing to traverse the whole DOM each time. I don't program JS, but wouldn't you have some variable holding the reference to the place you want to update? Like you have a DOM element that will be updated every second, you would surely not search the whole DOM every second, but get it once and udpate it multiple times? No?
If you have a table and want to edit information this is trivial to do in a React like way without React. Edit button stores reference to the row, edit values, update data store, render out new row element, remove element, insert new element. Yes, React will generally be less code and the argument becomes whether this is more complex, which it is, but I'd say neither the complexity or performance truly suffer. I bet the performance will be faster as you removed diffing entirely and React will have to perform your logic anyway.
This would cast doubts on some of the theoretic claims on the React docs, at least for mobile.