6 ms·

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

by throwaway220033 3y ago

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.

iamflimflam1 3y ago
Can't help but agree. It's very hard, even for experienced developers, to understand what is going on with hooks. 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.
- pavlov 3y ago
  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?
- _heimdall 3y ago
  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.
- danielvaughn 3y ago
  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.
- Timon3 3y ago
  > 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.
rpastuszak 3y ago
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.
- dgellow 3y ago
  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.
slmjkdbtl 3y ago
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.
- nusl 3y ago
  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.
- lakpan 3y ago
  React is fine, but what is going on with RTK? So. Much. Boilerplate.
  - acemarke 3y ago
    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?
    - lakpan 3y ago
      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.
      - acemarke 3y ago
        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: - https://redux.js.org/usage/migrating-to-modern-redux https://redux.js.org/usage/migrating-to-modern-redux as well as the "Style Guide" best practices page: - https://redux.js.org/style-guide/ https://redux.js.org/style-guide/
revscat 3y ago
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.
technion 3y ago
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.
- _heimdall 3y ago
  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.
  - colonelpopcorn 3y ago
    Most of the core React devs are employees at Vercel. As much as you may not like it, core parts of React are driven by Vercel 's business model.
    - tubthumper8 3y ago
      Most? Looks like 3 out of 20 people https://react.dev/community/team https://react.dev/community/team
    - addicted 3y ago
      Is React no longer a Facebook/Meta project?
mstade 3y ago
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!
throwaway257ash 3y ago
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?
lairv 3y ago
I agree but a major selling point of React is its ecosystem, and libraries are not compatible with Preact by default
- gardnr 3y ago
  Which libraries have you had trouble using? The official preact/compat library works great for me https://preactjs.com/guide/v10/switching-to-preact/ https://preactjs.com/guide/v10/switching-to-preact/
sunaurus 3y ago
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 3y ago
  > 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 3y ago
    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-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... [1] https://github.com/flutter/flutter/issues/51752 https://github.com/flutter/flutter/issues/51752
  - selfmodruntime 3y ago
    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?
satvikpendem 3y ago
> 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. [0] https://github.com/flutter/flutter/issues/51752 https://github.com/flutter/flutter/issues/51752
- throwaway220033 3y ago
  > No, it had nothing to do with making it "simpler for beginners." Open up the announcement of hooks by Dan Abramov and listen him.
- codethief 3y ago
  > 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] Interesting. I assume you are referring to this comment in particular -> https://github.com/flutter/flutter/issues/51752#issuecomment-665380355 https://github.com/flutter/flutter/issues/51752#issuecomment... ?
  - satvikpendem 3y ago
    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.
azangru 3y ago
> 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?
- azangru 3y ago
  Examples from the conversations of that time: > ...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-477886602 https://github.com/reactjs/rfcs/pull/68#issuecomment-4778866... [1] - https://tkplaceholder.io/why-function-components-fit-react-better-than-classes https://tkplaceholder.io/why-function-components-fit-react-b...
synergy20 3y ago
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.
deleted 3y ago
[deleted]

iamflimflam1 3y ago

Can't help but agree. It's very hard, even for experienced developers, to understand what is going on with hooks. 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.

pavlov 3y ago
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?
_heimdall 3y ago
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.
danielvaughn 3y ago
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.
Timon3 3y ago
> 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.

rpastuszak 3y ago

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.

dgellow 3y ago
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.

slmjkdbtl 3y ago

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.

nusl 3y ago
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.
lakpan 3y ago
React is fine, but what is going on with RTK? So. Much. Boilerplate.
- acemarke 3y ago
  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?
  - lakpan 3y ago
    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.
    - acemarke 3y ago
      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: - https://redux.js.org/usage/migrating-to-modern-redux https://redux.js.org/usage/migrating-to-modern-redux as well as the "Style Guide" best practices page: - https://redux.js.org/style-guide/ https://redux.js.org/style-guide/

revscat 3y ago

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.

technion 3y ago

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.

_heimdall 3y ago
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.
- colonelpopcorn 3y ago
  Most of the core React devs are employees at Vercel. As much as you may not like it, core parts of React are driven by Vercel 's business model.
  - tubthumper8 3y ago
    Most? Looks like 3 out of 20 people https://react.dev/community/team https://react.dev/community/team
  - addicted 3y ago
    Is React no longer a Facebook/Meta project?

mstade 3y ago

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!

throwaway257ash 3y ago

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?

lairv 3y ago

I agree but a major selling point of React is its ecosystem, and libraries are not compatible with Preact by default

gardnr 3y ago
Which libraries have you had trouble using? The official preact/compat library works great for me https://preactjs.com/guide/v10/switching-to-preact/ https://preactjs.com/guide/v10/switching-to-preact/

sunaurus 3y ago

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 3y ago
> 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 3y ago
  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-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... [1] https://github.com/flutter/flutter/issues/51752 https://github.com/flutter/flutter/issues/51752
- selfmodruntime 3y ago
  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?

satvikpendem 3y ago

> 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. [0] https://github.com/flutter/flutter/issues/51752 https://github.com/flutter/flutter/issues/51752

throwaway220033 3y ago
> No, it had nothing to do with making it "simpler for beginners." Open up the announcement of hooks by Dan Abramov and listen him.
codethief 3y ago
> 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] Interesting. I assume you are referring to this comment in particular -> https://github.com/flutter/flutter/issues/51752#issuecomment-665380355 https://github.com/flutter/flutter/issues/51752#issuecomment... ?
- satvikpendem 3y ago
  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.

azangru 3y ago

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

azangru 3y ago
Examples from the conversations of that time: > ...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-477886602 https://github.com/reactjs/rfcs/pull/68#issuecomment-4778866... [1] - https://tkplaceholder.io/why-function-components-fit-react-better-than-classes https://tkplaceholder.io/why-function-components-fit-react-b...

synergy20 3y ago

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.

deleted 3y ago

[deleted]