3 ms·

> 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 `thi

> 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"?
- engineeringwoke 4y ago
  > 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.
  - acemarke 4y ago
    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.

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"?

engineeringwoke 4y ago
> 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.
- acemarke 4y ago
  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.