I don't know that I agree with that. I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist.
We have reached a period of time where junior devs exist that did not cut their teeth on class components and have no idea of what the lifecycles are. They don't know how rendering works so they either throw up useless memoization everywhere or they don't bother to think of it.
The complexity of class components did not vanish. It was only swept under the rug. Take useEffect. It's overloaded to hell and back. It does too much and people continue to struggle with it. Another one, useRef. It's not really for refs, per se. You will end up using it for data other than refs because function instance variables aren't a thing. No one knows when to use useLayoutEffect or useCallback.
The fact of the matter is that it's not class components vs. hooks. It's that React's API sucks. It's always sucked. And it continues to suck.
> I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist.
And then it just stays fixed. You don't have to split up the logic across different lifecycle methods and remember to keep them in sync. They're consolidated into functions that can be trivially pulled out into their own hooks and reused.
React is definitely a more low-level framework that requires you to have some familiarity with how the scheduler works, and could benefit from a couple more built-in hooks. But the benefits are undeniable, they make writing and refactoring complex applications an absolute breeze. The fact that you can factor out some state-related behavior into a hook and trivially reuse it is incredible.
For example, take state. With hooks, you use useState. A very common pattern is to need to persist it in the URL to enable deep linking. You can literally just replace your useState call with useQueryParam from the use-query-params library [1] and have your component function identically. You just can't do that with class-based components.
Oh yeah, that's the worst. Since logic related to a behavior must be split up across multiple methods, it's really hard to tell if you've actually implemented it correctly. With effects, the setup and teardown is in the same function and can be moved around as a unit.
