2 ms·
mmm not quite. Step 1 would be slow if it created it in a real dom but as it's not (that's why it's called a "Virtual DOM") and is in fact just an object repre
by abritinthebay 11y ago
mmm not quite.
Step 1 would be slow if it created it in a real dom but as it's not (that's why it's called a "Virtual DOM") and is in fact just an object representation of the dom it's actually rather fast.
After all - it's just an object tree, and that's quite fast to parse.
The diff part is probably the slowest part in the React chain actually - because it actually has to compare to the other (virtual) representation of the DOM. Deep comparisons are just... well they'll never be trivial.
But no, it's really not extra thinking, it's not error prone, and it's basically due to it not really being what you're describing it as.
- amelius 11y agoI think you totally missed the point. Let's say that you have a page containing a billion little images. On every update, your React-enabled code needs to create a virtual DOM containing all those images. This takes time, regardless of whether the virtual DOM is fast. Hence my point. And even if it may be only a few milliseconds for a hundred images, it will take seconds or even minutes for millions of images. And even if only 1 of the images changed. This is of course not acceptable. Most programmers are already happy if it works for 100 images. However, imagine that the inventor of quicksort invented bubblesort instead, stating it is fast enough for 100 elements. From a CS point of view, this situation is just ridiculous.