[brundolf]

My org just got done investigating the advantages and disadvantages of memoizing by default, and we decided to make it a default policy, because for a large org it's better to have a recommended best-practice that's going to make things perform better more often than not. Devs are still free to do otherwise if they profile and find a case where it causes harm, but frankly I don't see that happening.

The appeal to authority in my original comment is not just deferring to trends or whatever; it's leaning on the deep knowledge (and inside-knowledge!) that a core React team member has of not only React's current implementation, but its underlying intents/philosophy (which informs which paths the team will focus on optimizing, for example), and even its future roadmap. I think it's legitimate to take those things into account, especially in the absence of any significant, concrete evidence showing that the practice in question can cause problems.

[darepublic]

> Devs are still free to do otherwise if they profile and find a case where it causes harm, but frankly I don't see that happening.

> I think it's legitimate to take those things into account, especially in the absence of any significant, concrete evidence showing that the practice in question can cause problems.

To me you are switching the burden of proof around from what it should be. What evidence do you have of the significant, concrete variety that wrapping every callback with useCallback, even if the deps array is empty, boosts performance?

[brundolf]

Re-rendering JSX subtrees is the main performance bottleneck in the majority of React apps. I should add that our decision includes the decision to start adding React.memo() to all components; otherwise, yeah, the benefits in most cases would be pretty small. But with React.memo(), useMemo/useCallback makes our components dramatically less likely to re-render, which again is the single biggest thing you can do for performance in most React apps. The difference is usually not perceptible on high-end dev machines, but a significant portion of our target market uses lower-end mobile devices to visit our site, so being performant-by-default is valuable to us.