The goal behind "hooks" was to make React simpler for beginners. I build client-side apps since 2007, and React is getting too magical and complex for even for me. The NextJS influence is really making things worse, "use server" "use client" tags do not scale at all. The project clearly lacks mission, goal, leadership and direction. I'll use Preact in the next projects.
> The goal behind "hooks" was to make React simpler for beginners
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.
> 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]
The whole thread is worth a read, the first post in particular lays out why traditional class-based solutions don't work, while that comment by Dan Abramov is good in its own way, viewing hooks through the lens of algebraic effect handlers.
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.
> 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.
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.
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?
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.
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:
> 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.
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.
I'm building frontend apps since 2012. I did not like hooks but ok fine. But NextJS seamed to became the default way of building React apps. I could never grasp how people in twitter and everywhere seemed to be fine with all this complexity it brought. All of this for reducing some milliseconds in load times? How can this be the default? With create-react-app you could just compile your app and host it at S3 with CDN for pennies. With NextJS you can do static site but you have to be aware of several gotchas. It seems like made up problem and solution to make return for the VC money, what am I missing?
I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.
I'm not on that level, but diving into React when you're not used to it is quite an experience. I've been asked to do it a few times as a most-backend/infra person. Good luck when the codebase is a mess though, cuz it seems like React spaghetti is a special breed of spaghetti.
There’s an interesting assumption here that frontend engineering should always be very simple, such that engineers in other disciplines should be able to hop over and dabble with frontend engineering on the side with no difficulty. Or perhaps the assumption is that React specifically should only focus on the fluffy, junior-friendly end of frontend and leave the more advanced frontend stuff to other toolkits?
I think React (hooks) invents a convoluted solution to a problem that can be solved in a more direct way, and there's a lot of big caveats hidden behind the interface that can cause big performance problem and bug. Their invention also requires a specific way of thinking that contradicts a lot of programming intuitions. Complexity is definitely fine if it comes from the problem itself (rendering), but for React most of the complexity is introduced by itself.
I'm confused why you feel embarrassed? Do you think they feel embarrassed that you can write React yet don't know how to write patches for the Linux kernel?
It's a different domain with a different skillset.
I meant I was embarrassed that these experienced engineers have to put up with some of the bad parts (I think) of web dev, that React (hooks) has a lot of unnecessary complexity and requires some unique mindset you have to train specifically for, unlike other frameworks have more direct and more intuitive solutions to the problem and I believe will be trivial for these engineers to get a grasp on.
Hi, I'm a Redux maintainer. I'm kind of confused by your comment in a couple ways.
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?
I’m neither a React nor Redux developer, but I work on React codebases. The code I see for simple changes is super verbose compared to what it would look like with simple hooks. I don’t know if it’s just my coworkers that suck at it.
Redux will never be the _absolute_ shortest way to write updates - it intentionally adds a level of indirection (the concept of "dispatching actions").
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:
> The goal behind "hooks" was to make React simpler for beginners.
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]
Personally I appreciate the ideas behind hooks, but the implementation feels like I’m trying to write in a different language behind JavaScript that has its own rules about scope, flow control, variable dependencies, and many other things that run counter to what appears to be happening on the JavaScript surface.
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 was able to grasp hooks after an initial distaste. But once I started hearing about hydration, I just felt this…weariness. It’s why I’ve never been interested in NextJS and definitely not interested in RSC.
I’m open to having my mind changed, but I really don’t like having abstractions cross the network boundary.
> Definitely feels like complex implementation details leaking upwards and influencing the public API.
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.
When hooks were first announced they had a bit of a "you probably shouldn't use this unless you're framework author" air to them.
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 have a similar experience to yours. I'm using preact for most things now, sveltekit for anything full-stack or when I need static generation (great fro small/mid-sized projects, haven't build anything "enterprise" with it).
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 haven’t done serious front end work since years, so I’m not up to date with recent solutions. The current project I contribute to has a Next.js app for its front end. The web app has maybe 4-5 pages, only one is pretty heavy (a sort of IDE like web UI). I’ve never experienced such a sluggish tool. next dev consumes a massive amount of memory and is really slow, next build takes minutes to compile pages… I’m pretty happy I’m not touching the front end regularly, I’ve mostly noticed the slow build times when creating a docker image (it takes ~10min to build in a CI context, most of that time is waiting for pnpm install and next build to finish) and setting up some continuous deployment pipelines.
I really feel bad for anyone who decided to go with that stack.
I have made hard decisions to fully return to vuejs for a few months, much simpler.React has lost itself totally thanks to vercel/next.js who hijacked oss projects for its short gain with VC's money.
If you look at their incentives differently, i would argue they doing well with their goals. Every "use server" is another vercel customer. Every preact user finds it harder to claim they are using react when apis showing up in react canary and being documented for nextjs don't exist for them.
React isn't a Vercel product though, and server components are a react feature rather than a NextJS feature.
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.
Same realization. I started playing around with Rails/Hotwire and found that to be much more productive and far simpler. Haven’t used it for anything “real” yet, but I am enjoying it so far.
I couldn't agree with you more, but sadly the amount of inertia around React makes it very difficult to ignore or supplant. Especially if you're in the business of providing any kind of developer tooling.
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!
