Am I Overreacting? Or is React Over-Reacting?
devtails.xyz
devtails.xyz
That's why I wrote an incredibly extensive article on this: "A (Mostly) Complete Guide to React Rendering Behavior". I'd strongly recommend reading through that to help internalize what React is doing and how re-rendering works:
- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
In general: yes, *React re-renders recursively by default*. Also: yeah, _no_ web app will update as efficiently as a 3D game engine, because it's under completely different technical constraints. On the other hand, web apps are also a completely different _kind_ of application than a 3D game as well, and the DOM is a different display environment than rendering 3D models and executing physics logic.
Also, the article said:
> I would like to acknowledge that there should be “some” overhead from using the development build, but I wouldn’t expect turning on production mode would have a substantial impact on this example.
There _is_ actually significant difference between dev and prod build performance. By default, profiling only works against development builds, but there's two ways you can try measuring the render time of a production build:
- Alert your build setup to alias "react-dom" to the special profiling build, which is a production-like build that still has the profiling logic enabled, then use the React DevTools Profiler to repeat this demo: https://kentcdodds.com/blog/profile-a-react-app-for-performa...
- You can also use the special `<Profiler>` component with a callback that captures and logs render timing data. Off the top of my head I can't remember whether it will report data with a true production build, or whether it also requires the "profiling" build. Either way, adding that to your component tree will give you the timings for each render pass, and you can log or do something with that data.
Agreed that some of the steps to optimize rendering behavior ( use of `React.memo()` and `useCallback()` ) can be annoying, but you also don't _need_ those all the time.
In general, React is not designed to be the absolute fastest way to update the UI. It _is_ designed to let you write encapsulated components that are straightforward to understand, and remove the need to think about _how_ the DOM gets updated. In most cases, the update performance _is_ "good enough" out of the box, without needing to do additional work to optimize that, and React does give you tools to improve that where needed.
I'll update the article with a production build. I originally planned to do it, but then copped out (partially because I wasn't sure how to, so thanks for the pointers).
I agree with your final statment, but have begun to wonder whether there's a simple enough way to accomplish the same goals, while being performant by default. We'll see where I land after further explorations.