Comment by buster | Hacker News Reader

Comment by buster | Hacker News Reader

Parent Full thread

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.

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?

>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.

Reply on news.ycombinator.com