To be fair hooks are kind of a frivolous feature that add no new functionality (just another way to do something we already could). It does irk me a bit when library maintainers do stuff like this because it just introduces more complexity and more patterns into a framework that people feel the need to tap into. Smart devs will just opt not to use hooks, but it sucks that the industry will likely adopt it for no reason other than keeping up with the latest trends.

React peaked at v16.

> Smart devs will just opt not to use hooks

Couldn’t disagree with you more here. Smart devs use smart abstractions. Hooks is a smart abstraction because 1) classes and inheritance don’t belong in JS, 2) they allow for more code reuse, 3) they allow you to write simpler, more declarative code.

> 1) classes and inheritance don’t belong in JS

You gonna back this claim up? Because it doesn't stand on its own. Inheritance certainly doesn't gel with _React_ (use composition), but to say it doesn't belong in JS is rather naive.

> 2) they allow for more code reuse

You can already get just as much reuse out of React's context API

> 3) they allow you to write simpler, more declarative code.

This is rather subjective, but I'd argue it's not simpler, because it "hides" the state with internal magic, and it's not even more declarative because using a context (or composition) based approach would be just as declarative.

I'd actually argue it's far more complex, because each invocation of `useEffect` doesn't even have the same result! There's some behind-the-scenes magic going on that makes it harder to reason about and find bugs.

The nice thing about having classes is that it's very easy to understand what code runs when a component is initialized (constructor and componentDidMount) versus what code is run on each render cycle (the render method). Hooks just removes that whole distinction and throws everything into one place. Devs who are new to React will definitely struggle with understanding what is going on behind the scenes.

It's not like React.Component is gone, either. Still there. I think it's still the only way to make an error boundary component, too.

He does have a point that churn/the new hotness is a real issue, and the latest hotness in JS library/framework have a very short shelf-life. On the other hand, projects like Babel or Polymer, that want to be obsolete at some point, but will require minimal re-writing when that happens are excellent and future-proof.

There is a far less framework churn now than there was 10 years ago. React, Angular, and Vue have all been around for a long time now relative to previous JS frameworks. React makes a lot of changes but they are, on average, improvements. Not all of them are the best decisions and some are temporary band aids to support new features, but the constant iteration in response to changing expectations for web is one of it's strengths IMO.

Angular 1 or 2? Cause the latter seems to be 3 years old. Okay, facile argument, the others are 5-6 years old from a quick search.

> React makes a lot of changes [...] the constant iteration in response to changing expectations for web

maybe it's ironic we're having that discussion on HN, and i'm struggling to remember sites that have gotten better lately, not worse. then again, that's probably because of the bias to remember negative experiences

"The new hotness" is not a problem. It is a problem when developers insist on using "the new hotness" regardless of whether it adds value. There are many thousands of applications using React without hooks that are working just fine and will continue to do so indefinitely.

Definitely not a novel point. Nor particularly accurate anymore as other commentators have pointed out.