When does React re-render? Explaining rerenders and how to optimize performance
&quot;React is known for providing a fast user experience by only updating the parts of the UI that have changed.&quot;<p>This is wrong. Naive React code is rarely fast in relative terms. This is because the whole design of React is <i>not</i> based on updating on the parts of the UI that have changed, but on re-rendering <i>everything</i>.<p>The whole concept of React, if you go back to the original &quot;rethinking best practices&quot; intro, was that Facebook wanted to bring the server-side practice of re-rendering the whole page for any change onto the client. This had the obvious advantage that, combined with normalised state flowing downward through the component tree, you would never end up with stale bits of UI, as everything would all always be kept up to date.<p>However, tearing down and re-creating the whole DOM for every single render was prohibitively expensive, so the virtual DOM was born. But, and this seems to get lost in a lot of discussions of React, VDOM wasn&#x27;t some magical leap forward in UI rendering performance. It was a performance technique to make React&#x27;s paradigm possible. Possible, but not inherently fast, because there is still a cost to re-rendering every component for every event. Any React developer who&#x27;s had to add React.memo to half their components, and add visualisation to lists of just a few hundred items should know this.<p>Having written several substantial apps with both React and some of its competitor frameworks, I&#x27;m always amazed to see React-only developers continue to labor under the delusion than it is the fastest framework out there. It is not. Its paradigm is a beautiful one to develop with in most ways, but there is a significant price to pay in terms of performance.