Many people aren't event aware of the unnecessary renders caused by using hooks. If your app is so tiny that it doesn't matter if everything renders all the time, then you might not be aware of your `useCallback` recreating callbacks way too often (https://github.com/facebook/react/issues/14099), or that you're not even using it in the first place. Considering that front end is probably the area of software development that attracts the largest share of people like me - self taught, no computer science background - I'd also assume that many people love the perceived simplicity of hooks without realizing that it makes their code worse.
It'll only become apparent when you app is large and complex enough that it suddenly starts to matter when things re-render and then you'll be faced with tracking down those re-renders and fixing dependency arrays everywhere.
With classes, the naive solution is the right one when it comes to preserving function identities across renders.
Not saying hooks are bad, but they're not all roses and sushine.
A lot of people don't understand that React's default behavior is to re-render _everything_.
When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that cares if it's a new function reference or not.
It's only when child components are attempting to optimize perf by comparing props and avoiding re-renders that having consistent callback function references matters (ie, `React.memo()`, `PureComponent`, and React-Redux's `connect()`).
Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: (https://reactjs.org/docs/optimizing-performance.html)
> Internally, React uses several clever techniques to minimize the number of costly DOM operations required to update the UI. For many applications, using React will lead to a fast user interface without doing much work to specifically optimize for performance.
My experience with React applications (both writing them and as an end-user) hasn't really borne this out.
This was also a huge part of the marketing push for years: if you listened to proponents, you have thought that the average app was bottlenecked on DOM updates, and that partial updates were too hard to do with anything else.
Could you elaborate? Rendering perf is pretty much the least of my concerns, even on my apps which support IE10. Most "perf" problems I find are related to fetching and appropriately caching data.
It's pretty easy to run into render performance issues with React, especially on older machines, when you have a very dynamic UI. At work, we dynamically generate several SVG charts and "badges" on certain pages. Putting even one of those onto a page without any optimization created about a half second delay between actions on my high-end machine, so we had to spend some time making sure that things weren't re-rendering needlessly and that DOM nodes were getting reused. But even if that seems like an atypical use case, we had similar issues rendering complex tables, purely due to the amount of DOM nodes needing to be put onto the page at once. So it might not be an everyday kind of problem, but I don't think it's uncommon to run into performance issues with React.
Not the parent, but here's one that I hit recently:
I hoisted the state of an input box up a few layers because other parts of my app are affected by the current typed content. Since I'd been careless passing closures in as props to expensive components, they were getting re-rendered on every keystroke. It was noticeably sluggish.
> re-renders that having consistent callback function references matters
That's the case I was talking about, I probably should have added that. In our codebase at work most components are using such optimizations but of course that's not the case for most people.
I have been working on an enterprise React App for the past 6 months using only the hooks API. The App is a non trivial Dashboard, displays various custom charts (done using d3 and manual SVG Elements in React) and some larger tables/forms. While I use useEffect() frequently, there is not a single useCallback/useMemo in the code.
I just profiled it on my 5 year old MacbookPro, and out of 50 commits or so, just a single one spiked above 20ms (which was the first commit, subsequent to same view were much faster) and almost all are in the <5ms range. I decided it is not worth doing any optimization yet, and I will defer useCallback/useMemo optimization until there is a real, noticeable delay in rendering.
It'll only become apparent when you app is large and complex enough that it suddenly starts to matter when things re-render and then you'll be faced with tracking down those re-renders and fixing dependency arrays everywhere.
With classes, the naive solution is the right one when it comes to preserving function identities across renders.
Not saying hooks are bad, but they're not all roses and sushine.