Hooks had nothing to do with v8 optimizations or `this.state`.

Per https://reactjs.org/docs/hooks-intro.html , the primary motivations were:

- "It’s hard to reuse stateful logic between components "

- "Complex components become hard to understand"

- "Classes confuse both people and machines" (remembering how `this` works, code minification, method binding, etc)

There's also an excellent "Why React Hooks?" post at https://ui.dev/why-react-hooks that gives background details.

Additionally, the React team has talked about how hooks and function components allow them to have "forks" of the component tree in various states of partial completion at a time, for use with Suspense and transition features. This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance.

One of the few reasonable comments in this thread.

Hooks are better than HOCs, no this is better than managing this, and dependency arrays are better than if (this.props.fooBarBaz !== newProps.fooBarBaz || this.props.onFooBarBazChanged !== newProps.onFooBarBazChanged || …)

You're very much misreading what I said.

It's not about "optimization" in the sense of "how fast can the v8 interpreter execute lookups on the class instance" or anything like that.

It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?

> It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?

You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks existed obviously. It's secondary to the discussion because function components have existed for a long time.

None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.

I'm legitimately curious. Can you point to a single actual source to cite "the React team made the change to hooks because of JS engine performance"? (and when you say "performance", you _are_ talking about literal instruction execution time / JIT behavior / etc, that sort of thing?)

I'm pretty deeply tied into the React ecosystem, and I honestly can't remember _ever_ seeing that mentioned as a justification.

If you can link me a reference with them saying that, I'd both be interested in reading it, but honestly surprised to see that stated at all.

It's just a prop access how is that hard for v8 to optimize? What were they doing to cause that to de-optimize?

Funny that this whole hooks mess could have probably been better resolved with investment in developing optimization patches for v8 rather than attempting to "fix" React

It would be funny if it were true. Hooks were made for composable behavior for components.

How would Facebook convince the community to dogfood their new API without some marketing buzz? It's pretty obvious that V8 has trouble optimizing changes to object properties because of the design of the spec, and they were also pretty open about it in the blogs where hooks were introduced. I think it's also clear that useEffect is harder to grok than it's lifecycle equivalents, so there might be other things at play than composability.

It's also a bit funny that certain kinds of people can just brush off these things with some non-sequitur on a message board when there are almost always bigger things at play.

I was just going off my own experience with React through the years. It was very hard to compose behavior with class based components. We had to create higher order components that had functions as children which could pass down data as arguments to the child function. It really made a mess of the component hierarchy. Now you can create reusable custom hooks that can be used from any component.

I agree with you. It's much better to have useAuth everywhere than having WithAuth capping every class.

My understanding as well though a lot of the details may be perf related..

Ultimately hooks are probably the way they are for the same reason Redux is the way it was(pre RTK I suppose)..