No, it had nothing to do with making it "simpler for beginners." It was to functionalize state changes in a way that was impossible with classes and other OOP constructs like mixins. There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0]. What people don't get about hooks is that they are an abstraction over state and app lifecycle changes. It is better to think of them as akin to closures but over lifecycles, not just holding state as closures do.
Interesting. I assume you are referring to this comment in particular -> https://github.com/flutter/flutter/issues/51752#issuecomment... ?
Open up the announcement of hooks by Dan Abramov and listen him.
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.
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.
[0] https://medium.com/@dan_abramov/making-sense-of-react-hooks-...
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.
> 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.
Hmmh. Can you provide me an example of what would've been "unclear" if the value was just state in a Class component?
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.
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.
It's a different domain with a different skillset.
I'm not sure why you're jumping to discussing Redux here - we're a completely separate project from React, and nothing about the parent comment mentioned Redux.
That said, we specifically created and designed RTK to _eliminate_ boilerplate, so I'm not sure what "boilerplate" you're referring to here. Could you give some specific examples? What concerns do you have?
That said, we specifically created Redux Toolkit to drastically simplify standard Redux usage patterns. Sadly, despite it being the default way to write Redux apps for several years now, there's still a lot of legacy Redux code that isn't following our recommended patterns.
See our "Migrating to Modern Redux" guide for details:
- https://redux.js.org/usage/migrating-to-modern-redux
as well as the "Style Guide" best practices page:
What makes you think this was the goal? React team has been trying to get rid of 'this' for a long time; I believe I saw someone say that it had some undesirable consequences for the fiber architecture and for the "concurrent mode" that eventually was transformed into a set of concurrent features. Alternatively, it is possible that they wanted a better reactivity model than the one based on component's lifecycle. Why does this necessarily have to be simpler for beginners?
> ...we want closures to capture the values we rendered with, and to keep "seeing" those values forever. That's really important for concurrent mode where a notion of current value doesn't really exist. Hooks design models a component as being in many non-clashing states at the same time, instead of switching the "current" state (which is what classes model well). People don't really need to think about these details, but they're motivating the design a lot. [0]
> In Concurrent Mode, render may run more then one time, and since this in a class is mutable, renders that should be the same may not be. [1]
[0] - https://github.com/reactjs/rfcs/pull/68#issuecomment-4778866...
[1] - https://tkplaceholder.io/why-function-components-fit-react-b...
Even knowing why they are needed requires a deep understanding of what is happening.
Definitely feels like complex implementation details leaking upwards and influencing the public API.
I’ve worked on many projects that implemented object-oriented programming in C, and the impedance mismatch there was much more tolerable. That should be a warning signal that something is amiss with hooks in JS.
They made an embedded language extension for JSX. Why not a similar separate language for hooks, to clearly delineate when you’re working with the React state machine rather than ordinary JS state?
I’m open to having my mind changed, but I really don’t like having abstractions cross the network boundary.
This describes it very well. I recently started writing React code after using Vue 3's composition API for a long time, and it's hard to explain just how much more low-level and manual the primitives feel.
I'm not sure if it was the react team adjusting the message and pushing for hooks in user code, or users throwing hooks at every problem when that wasn't recommended, but it definitely got odd track.
I still like hooks for internal code in libraries and frameworks, but they ruin client code IMO. Unfortunately hooks are here to stay and there's really no way to avoid them in most apps today.
I wish Remix was preact. It looks like it has parts of preact and svelte I really enjoy.
I've been using Next.js since 2016/17 at small and large SaaS scale) -- I feel like they're building it like a VS funded SaaS now. The added complexity doesn't really pay off.
I really feel bad for anyone who decided to go with that stack.
With regards to incentives, these newer react features only meet their goals if the goal is to use react the open source project as a funnel for Vercel, the for profit hosting company.
The project I'm most excited about in recent years is htmx. Sadly I've yet to have the opportunity to work on any real projects with it. Some day, fingers crossed!