To be fair, he was pretty clear about the reason for it:
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!
To me only lesson seems to be, this is how React works. The diffing is known to work like this, if you are not calculating the diffs beforehand (or use some non-standard ways to set the state) there is not much one can do besides obvious things like immutables. Diffing massive tables against each other each time is sure slow.
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.
The point of the benchmark is that it's obviously not the DOM manipulation that is slow but the JS part. So moving as much as possible away from DOM manipulation to JS heavy lifting can, in theory, result in performance loss.
That's pretty much all the benchmark says (and seems to show). Now, the test case is some synthetic benchmark, but unless you take some time to program Facebook in React and in plain JS and do testing, you'll need to take some shortcuts.
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
It's a contrived example. The DOM manipulation is fast in this case because it's a simple appendChild every time. In other cases like where elements in the middle of a table are updated, you would get into a mess writing vanilla code, either complexity or performance wise, because you'd have to traverse the DOM to get to where you need to do updates and do each update individually. React batches such things together, and does one single update.
>In other cases like where elements in the middle of a table are updated, you would get into a mess writing vanilla code, either complexity or performance wise, because you'd have to traverse the DOM to get to where you need to do updates and do each update individually.
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.
I think it is out of question that a framework shields you from some complexity. That's the purpose of it.
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?
Without speaking for Paul, my understanding is that he is just appending to a list which in theory should be a simple diff right? Anyway, we are trying to get the source open asap, we just have a rather bizarre need to got through a release process.
Comparing to vanilla JS provides a good benchmark as to how much the cost is to use a particular library. To provide an example, the Angular team has claimed in talks a few months ago that Angular 2's performance is already close to pure JS for rendering large numbers of DOM elements (I hesitate to say anything about how complex the trees are since I don't remember the details) - profiling is built into the repository itself.
This would cast doubts on some of the theoretic claims on the React docs, at least for mobile.
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!