[sunaurus]

I've seen this criticism several times on HN, but have never been able to relate to it.

I've been using hooks since they were introduced, in several teams (at several different companies), and I've never experienced them being complicated to understand, either for myself, or for team mates - even juniors who are new to React. In my experience, it takes very little time (<1 hour) to understand the basics of React, and once you have that mental model in place, hooks fit in immediately.

I wonder if it's the case that many people on HN are just used to some completely different libraries and thus are coming in to React with a completely different mental model? And that's the cause of this sentiment being so common here.

[baobabKoodaa]

> I wonder if it's the case that many people on HN are just used to some completely different libraries and thus are coming in to React with a completely different mental model? And that's the cause of this sentiment being so common here.

Nope. For me React was the first frontend framework I learned. The mental model of Class components was really easy to understand. I have since "learned" hooks, but they are a constant source of mental exertion for me, and it's very easy to make mistakes. Kind of like all the other "improvements" that they brought to React since Class components.

[satvikpendem]

You might be interested in learning the reason hooks were invented [0]. I also use hooks in Flutter via a separate package and its creator made a great GitHub issue talking about exactly why class components cannot replicate the hook model [1], simply due to the limitations of how classes work. The code is in Dart but it's simple enough to grasp if you know JS and class concepts in general like overrides and mixins.

[0] https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

[1] https://github.com/flutter/flutter/issues/51752

[selfmodruntime]

I do not get that class components are in any way simpler. Before, you had to think about explicit configuration states during the components entire lifecycle. Now, you just... don't?

[baobabKoodaa]

Previously everything was explicitly in your code. Now everything is done with "magic" outside your code. You're saying that this is better because now I "don't have to think about it". But I do! When something doesn't work, you have to figure it out. It's easier to debug code that you can see and reason with, and more difficult to debug a black box that behaves in mysterious and unexplainable ways.

What you're probably thinking is "it's faster to write a TODO example app with hooks". That's not really relevant for actual software development.

It seems that framework creators are constantly making tradeoffs where they are making the easy things easier at the expense of making the hard things harder. That's the wrong tradeoff to make.

[sunaurus]

That's interesting. My feeling is that things became MORE explicit with hooks, not less, so I'm quite confused still.

> What you're probably thinking is "it's faster to write a TODO example app with hooks". That's not really relevant for actual software development.

For me, that's not the case at all. I think with hooks, it's easier to reason about what values are actually used during what renders.

[baobabKoodaa]

> For me, that's not the case at all. I think with hooks, it's easier to reason about what values are actually used during what renders.

Hmmh. Can you provide me an example of what would've been "unclear" if the value was just state in a Class component?

[addicted]

I can objectively prove that React devs themselves have at the very least changed how they understand hooks but more likely have been making it up as they’ve gone along. The best example is one of the more problematic hooks, useEffect.

Here’s how useEffect is described in the old documentation:

https://legacy.reactjs.org/docs/hooks-effect.html

> The Effect Hook lets you perform side effects in function components

Here’s how the new docs explain useEffect:

> useEffect is a React Hook that lets you synchronize a component with an external system.

These are dramatically different claims about what useEffect is supposed to be for. Dig a little deeper and Reaft developers will now explicitly tell you to not use useEffects for side effects, which again is the opposite of what they explained it to be.

The same change in how they’re actually supposed to be used has been true across all the books to a lesser or greater degree.

Maybe React has finally stabilized and it’s easier for new devs because they’re learning the more stabilized version. However, I suspect it’s easy because they just happen to be within the same cycle of understanding in React. Much like how React was easy for devs coming to it nearly a decade ago, until the devs changed everything about it. New devs may just not be deep enough into the new cycle to experience the pain of all your understanding being wrong.

Now, to be completely clear, I have no problem with the changes. I think change is good and I have successfully worked with languages where the change has been even more dramatic than React.

The difference with React, I’ve increasingly come to realize, is that the developers will make radical changes in how they understand it to work, while still gaslighting you that nothing really has changed.

Hence the massive effort they made to convince everyone that hooks were just a different approach as classes and they both would be first class citizens forever, when they first introduced hooks, only to subtly and quietly change the narrative to hooks being the future of Reaft and recommending hooks.

They make these shifts all over the place without ever announcing it and convincing you to believe that what they’re saying today has always been the case.

More honesty towards how they’re changing React and what those changes mean would have gone a long way to reduce the absolute confusion floating around the react world.

[wk_end]

I think it’s more that the React team’s way of articulating their idea of what a “side effect” is changed than that their idea of what useEffect is for changed. The examples of “side effects” in the old docs are all cases of “external synchronization”. People found the old terminology misleading because they came with their own preconceptions of what a side effect is, so they changed their pedagogical approach. The technical details haven’t really changed, just the presentation.

[ActionHank]

I've worked on some pretty complex client side code and frankly react hooks are meh at best.

There is a very strong implication in the docs and even the overall solution of hooks to ignore the details and just "go with it".

Just do it™ our way™ because reasons™

Generally not healthy for building the level of understanding it takes to debug complex react code.

Also I deeply on a spiritual level detest the way that it very strongly incentivizes pushing business logic to the view layer.