Did you actually build anything with Hooks? I was pretty turned off by it at first sight as well. It doesn't jive with the sensibilities of a class based OOP developer's natural instincts. But once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about. No more component lifecycles and massive class files.
The proposition of hooks is that they do accomplish the same things as class lifecycle methods do, just in a different way, so all the underlying complexity must still be there by definition.
This discussion reminds of this little parable[1]
> The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
> On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
I don't think it's that you don't have to worry about lifecycles, in the end. You still do - you have to understand the lifecycles of your functions which are different than those of a component class, but they are lifecycles in there own way. What I think really makes hooks feel nice is you can _close over_ the small, self-contained lifecycles, and introduce them at any point in the program in a composable way. That's pretty neat actually, and what we've taken away from hooks currently.
Maybe that's not the only benefit they have, but it's a pretty large one, so I'm glad hooks decided to explore this new direction, even if I'm not completely sold on it (as in, wouldn't introduce it in Ember just yet).
This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.
I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.
Sure. But the point is that the entire class syntax becomes superfluous once you do that. Everything becomes a pure functional component, and you can just throw in a `useEffect` wherever the need for lifecycle based side effects arises.
You have been doing it wrong. Don't put business logic into visual components. UI technologies tend to be a fad. Business logic needs to live longer than UI technologies, and needs to be separated from UI components for testability, maintainability, reusability and longevity.
What I dislike: They promote patterns that go against long-standing "best practices". (Should we really be defining functions over and over and over again?)
So, the biggest advantage, is also my biggest gripe.