7 ms·

It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-e

It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases

ferdowsi 4y ago
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
- nightski 4y ago
  It would be funny if it were true. Hooks were made for composable behavior for components.
  - Rapzid 4y ago
    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)..
  - engineeringwoke 4y ago
    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.
    - nightski 4y ago
      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.
      - skydhash 4y ago
        I agree with you. It's much better to have useAuth everywhere than having WithAuth capping every class.
Rapzid 4y ago
It's just a prop access how is that hard for v8 to optimize? What were they doing to cause that to de-optimize?
acemarke 4y ago
Hooks had nothing to do with v8 optimizations or `this.state`. Per https://reactjs.org/docs/hooks-intro.html 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 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.
- srcreigh 4y ago
  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 || …)
- engineeringwoke 4y ago
  > This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance. So `this.state` is hard to optimize? > Hooks had nothing to do with v8 optimizations or `this.state`. Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.
  - acemarke 4y ago
    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"?

ferdowsi 4y ago

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

nightski 4y ago
It would be funny if it were true. Hooks were made for composable behavior for components.
- Rapzid 4y ago
  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)..
- engineeringwoke 4y ago
  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.
  - nightski 4y ago
    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.
    - skydhash 4y ago
      I agree with you. It's much better to have useAuth everywhere than having WithAuth capping every class.

Rapzid 4y ago

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

acemarke 4y ago

Hooks had nothing to do with v8 optimizations or `this.state`. Per https://reactjs.org/docs/hooks-intro.html 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 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.

srcreigh 4y ago
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 || …)
engineeringwoke 4y ago
> This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance. So `this.state` is hard to optimize? > Hooks had nothing to do with v8 optimizations or `this.state`. Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.
- acemarke 4y ago
  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"?