6 ms·

I'm not in frontend mainly, but this article, and another short I watched about how useEffect is almost always wrong makes me feel uneasy about React. It's insi

I'm not in frontend mainly, but this article, and another short I watched about how useEffect is almost always wrong makes me feel uneasy about React. It's insidiously complex. A bunch of `useCallbacks` are rendered ineffective because the top of the chain wasn't properly computed. And the fix isn't `useCallback`, its to rearchitect the tree. This feels wrong - either the API, the framework, or the language isn't powerful enough to ensure that someone does the right and performant thing. It seems like the new React Compiler tries to fix this - but I'm surprised React Compiler is a thing that needs to be built.

eterm 1y ago
It's a huge mess in the real world. Without good understanding and discipline, I've seen components which react profiler says re-render 15 times on an initial load because of cascading useEffect hooks. I lack the expertise to be able to go in and rip it all out, and while I can share articles like this and others such as "You might not need useEffect", there isn't a really obvious way to deal with it all, especially if there are places which genuinely could do with proper memoisation.
wredcoll 1y ago
I do frontend and I also feel uneasy about react. I stand by my assertion that it's trying to solve a hard problem and thus might actually require complex code, but still, the way react structures things with `useFoo` feels like they've really missed some easier ways to do it.
- alisonatwork 1y ago
  I'm mostly backend but have been fullstack in a few positions and remember expending a bunch of political capital advocating for moving to React when it first came out because it seemed to solve a lot of problems we were having with projects that used Angular or a jQuery patchwork. I still think that it was the right decision at the time, but what React has become today is so much more esoteric and spaghetti-like that I'm not sure having it "win" was the best thing for frontend. Now I actively go out of my way to avoid doing any fullstack because I spend more time trying to fight against the various fragile towers of incantation-like hooks than just implementing the business logic in a way that feels readable and maintainable. I'm not sure there is a way to remove the complexity either, but so much of modern programming with React just feels unintuitive and convoluted, which is exactly the opposite of how it used to feel when it first came out. I'm not sure how to solve it.
  - leptons 1y ago
    >which is exactly the opposite of how it used to feel when it first came out. I use React (actually Preact), but the old way, not with "use" anything, no hooks. It's pretty simple, but does a good job at what I need, and I'm doing pretty complex web applications with it. There's no law saying you must use the bleeding edge of everything, the old React way is still plenty good for most things. The way they rushed out hooks and everyone jumped on board was a red flag for me. I've used it, I've built stuff with hooks, but it's always seemed like fixing problems by creating more problems, and the hype around it was ridiculous.
    - wredcoll 1y ago
      I feel the same way about vue switching to hooks. What is the exact problem we're solving?
    - agos 1y ago
      Hooks were introduced in early 2019, they're hardly bleeding edge
      - leptons 1y ago
        I was not specifically talking about hooks being "bleeding edge" in 2025. I know when they were first released, and I don't need that techsplained to me. I'm speaking more generally about the trend of chasing "new, shiny" in front-end. Some people knee-jerk and just go for the "new, shiny" thing as soon as it happens. And other people still use the existing tech, because it's good enough.
    - skydhash 1y ago
      I switch to hooks the moment they were in stable. Because functional components are simpler in nature. And the reactive apparatus that hooks are make it simpler to bring external modules. Writing HOC was a pain. Hooks are a good translation layer.
      - bavell 1y ago
lmm 1y ago
> This feels wrong - either the API, the framework, or the language isn't powerful enough to ensure that someone does the right and performant thing. It's the language. React uses a bunch of magic methods and requires you to follow rules about when to call them, with limited guardrails, because if you try to make developers do this properly (with higher-kinded types and monads) they throw their toys out of the pram. Our culture prefers "there are a bunch of subtle rules you have to follow and if you break them you'll get weird bugs or performance issues" to "there are a bunch of explicit rules you have to follow and if you break them your code won't compile", sadly.
- wk_end 1y ago
  Is there something out there (in TypeScript, preferably) that does things in the way that you’re describing?
  - vermilingua 1y ago
    Svelte is a lot closer to that latter style, there are a lot of React weirdnesses that just aren’t possible in Svelte (because it’s a compiler, not a framework)
    - 5Qn8mNbc2FNCiVV 1y ago
      I'd rather break my hands than use Svelte instead of React again. It comes with so many problems of itself. Summarized in a single sentence though it would be: It's more common than you'd like it to be, that your UI doesn't actually reflect the state of your application.
      - agos 1y ago
        I was considering investing in learning Svelte to avoid some of the React quirkiness, but this is not very promising. Can you share a bit more? Trading off a set of quirky annoying things for an equivalent or worse one would be suboptimal.
efortis 1y ago
Yes, but in all fairness that’s React 16.8+ (2019) Before that you could write: class Page extends React.Component { componentWillReceiveProps(nextProps) { if (nextProps.url !== this.props.url) logVisit(nextProps.url, this.state.nItems) } } The upcoming `useEffectEvent` will make React even more cryptic and convoluted. const Page = ({ url }) => { const onVisit = useEffectEvent(visitedUrl => { logVisit(visitedUrl, nItems) }) useEffect(() => { onVisit(url) }, [url]) }
- c-hendricks 1y ago
  React.Component still exists. And most `useLatest` implementations will get you the advantage of `useEffectEvent` today. If you really wanted to take a jab at React people, show them const that = useLatest({ // bunch of stuff you want to pass around to effects / callbacks })
schwartzworld 1y ago
The issues with useEffect come from a misunderstanding of how data is meant to flow in react, the fundamental concept on which the whole thing is based. It’s not complicated at all.
- mmis1000 1y ago
  "It works when you do it correctly" isn't really a good argument when discussing UX/DX design in my opinion. Anything that isn't broken will also work when you use it correctly. The question is "how easy to do it correctly?". A poorly designed UX/DX takes user a lot of effort to use it correctly (macdonald's never fixed icecream machine). While a proper designed one allow the user to onboard easily withoud too much training.
  - schwartzworld 1y ago
    > The question is "how easy to do it correctly?" It’s quite easy. The complaints people have about it are due to friction from using it wrong.
  - skydhash 1y ago
    It’s very easy to do correctly. Hooks is a translation layer. Move everything that is not directly UI out of the component tree and let hooks bring it in. I’ve seen code where people dump the entire business logic into a component. Which is not good design.
    - mmis1000 1y ago
      I think the mvc era that business logic and view logics is separated completely has gone for a long time. No matter you like it or not. Or probably 'everyone' are using react wrong includes vercel...etc. But in latter case, it's still a giant dx issue. A framework that encourage you to use it incorrectly is not good. And keeps in mind, react hook until 18 (a long time since hook introduced) didn't offer a official way to connect component to external changing data. The only way you can do is by using useEffect incorrectly.
mmis1000 1y ago
I had do frontend for decades and witness the Jquery => Angular.js => React/Vue (Class) => React/Vue (Hook) transition. And out of them, the react hook is the only one that 'doing it wrong' is easier. A good API interface should have least resistance for the user when doing things correctly. But React Hook almost feels like the complete opposite of this phenomenon. It's complex, comes with tons of foot gun. And yet still get popular? Wondering if there is something other like this exists in the computer history.
- skydhash 1y ago
  Because it’s very simple. React is only a view layer that promises that your UI will always reflect your state. Bugs is usually when people brings in things that has no place being there. Aka no discipline in separating the view module from everything else.
5Qn8mNbc2FNCiVV 1y ago
The trick is to not worry about useMemo and useCallback because it's rarely an issue unless you have 800 line components or don't compose but rather treat everything as if it was inheritance. I've got pretty sizeable codebases, less than 5 useEffects ever (nowadays I only have one for a single location where I need to manually poll, the rest is useSyncExternalStore) and I only do useMemo for tables. Compiler is just an additional performance improvement that's "free" and at least the compiler doesn't make it harder to understand how your code executes because it just works
pjmlp 1y ago
React is the Git of UIs, the Vulkan, or whatever example you feel more apt for its ways of working, and changes across versions. Unfortunely, it has won the mindshare game, in many SaaS products I tend to work on, they only provide React and by extension Next.js based SDKs, if I want to use vanila.js, Angular, Vue or whatever, it is on me to make it work, if it is possible at all, given the product expectations on its extension points. Eventually the "everything must be React" wave is going to pass, hopefully.

eterm 1y ago

It's a huge mess in the real world. Without good understanding and discipline, I've seen components which react profiler says re-render 15 times on an initial load because of cascading useEffect hooks. I lack the expertise to be able to go in and rip it all out, and while I can share articles like this and others such as "You might not need useEffect", there isn't a really obvious way to deal with it all, especially if there are places which genuinely could do with proper memoisation.

wredcoll 1y ago

I do frontend and I also feel uneasy about react. I stand by my assertion that it's trying to solve a hard problem and thus might actually require complex code, but still, the way react structures things with `useFoo` feels like they've really missed some easier ways to do it.

alisonatwork 1y ago
I'm mostly backend but have been fullstack in a few positions and remember expending a bunch of political capital advocating for moving to React when it first came out because it seemed to solve a lot of problems we were having with projects that used Angular or a jQuery patchwork. I still think that it was the right decision at the time, but what React has become today is so much more esoteric and spaghetti-like that I'm not sure having it "win" was the best thing for frontend. Now I actively go out of my way to avoid doing any fullstack because I spend more time trying to fight against the various fragile towers of incantation-like hooks than just implementing the business logic in a way that feels readable and maintainable. I'm not sure there is a way to remove the complexity either, but so much of modern programming with React just feels unintuitive and convoluted, which is exactly the opposite of how it used to feel when it first came out. I'm not sure how to solve it.
- leptons 1y ago
  >which is exactly the opposite of how it used to feel when it first came out. I use React (actually Preact), but the old way, not with "use" anything, no hooks. It's pretty simple, but does a good job at what I need, and I'm doing pretty complex web applications with it. There's no law saying you must use the bleeding edge of everything, the old React way is still plenty good for most things. The way they rushed out hooks and everyone jumped on board was a red flag for me. I've used it, I've built stuff with hooks, but it's always seemed like fixing problems by creating more problems, and the hype around it was ridiculous.
  - wredcoll 1y ago
    I feel the same way about vue switching to hooks. What is the exact problem we're solving?
  - agos 1y ago
    Hooks were introduced in early 2019, they're hardly bleeding edge
    - leptons 1y ago
      I was not specifically talking about hooks being "bleeding edge" in 2025. I know when they were first released, and I don't need that techsplained to me. I'm speaking more generally about the trend of chasing "new, shiny" in front-end. Some people knee-jerk and just go for the "new, shiny" thing as soon as it happens. And other people still use the existing tech, because it's good enough.
  - skydhash 1y ago
    I switch to hooks the moment they were in stable. Because functional components are simpler in nature. And the reactive apparatus that hooks are make it simpler to bring external modules. Writing HOC was a pain. Hooks are a good translation layer.
    - bavell 1y ago

lmm 1y ago

> This feels wrong - either the API, the framework, or the language isn't powerful enough to ensure that someone does the right and performant thing. It's the language. React uses a bunch of magic methods and requires you to follow rules about when to call them, with limited guardrails, because if you try to make developers do this properly (with higher-kinded types and monads) they throw their toys out of the pram. Our culture prefers "there are a bunch of subtle rules you have to follow and if you break them you'll get weird bugs or performance issues" to "there are a bunch of explicit rules you have to follow and if you break them your code won't compile", sadly.

wk_end 1y ago
Is there something out there (in TypeScript, preferably) that does things in the way that you’re describing?
- vermilingua 1y ago
  Svelte is a lot closer to that latter style, there are a lot of React weirdnesses that just aren’t possible in Svelte (because it’s a compiler, not a framework)
  - 5Qn8mNbc2FNCiVV 1y ago
    I'd rather break my hands than use Svelte instead of React again. It comes with so many problems of itself. Summarized in a single sentence though it would be: It's more common than you'd like it to be, that your UI doesn't actually reflect the state of your application.
    - agos 1y ago
      I was considering investing in learning Svelte to avoid some of the React quirkiness, but this is not very promising. Can you share a bit more? Trading off a set of quirky annoying things for an equivalent or worse one would be suboptimal.

efortis 1y ago

Yes, but in all fairness that’s React 16.8+ (2019) Before that you could write: class Page extends React.Component { componentWillReceiveProps(nextProps) { if (nextProps.url !== this.props.url) logVisit(nextProps.url, this.state.nItems) } } The upcoming `useEffectEvent` will make React even more cryptic and convoluted. const Page = ({ url }) => { const onVisit = useEffectEvent(visitedUrl => { logVisit(visitedUrl, nItems) }) useEffect(() => { onVisit(url) }, [url]) }

c-hendricks 1y ago
React.Component still exists. And most `useLatest` implementations will get you the advantage of `useEffectEvent` today. If you really wanted to take a jab at React people, show them const that = useLatest({ // bunch of stuff you want to pass around to effects / callbacks })

schwartzworld 1y ago

The issues with useEffect come from a misunderstanding of how data is meant to flow in react, the fundamental concept on which the whole thing is based. It’s not complicated at all.

mmis1000 1y ago
"It works when you do it correctly" isn't really a good argument when discussing UX/DX design in my opinion. Anything that isn't broken will also work when you use it correctly. The question is "how easy to do it correctly?". A poorly designed UX/DX takes user a lot of effort to use it correctly (macdonald's never fixed icecream machine). While a proper designed one allow the user to onboard easily withoud too much training.
- schwartzworld 1y ago
  > The question is "how easy to do it correctly?" It’s quite easy. The complaints people have about it are due to friction from using it wrong.
- skydhash 1y ago
  It’s very easy to do correctly. Hooks is a translation layer. Move everything that is not directly UI out of the component tree and let hooks bring it in. I’ve seen code where people dump the entire business logic into a component. Which is not good design.
  - mmis1000 1y ago
    I think the mvc era that business logic and view logics is separated completely has gone for a long time. No matter you like it or not. Or probably 'everyone' are using react wrong includes vercel...etc. But in latter case, it's still a giant dx issue. A framework that encourage you to use it incorrectly is not good. And keeps in mind, react hook until 18 (a long time since hook introduced) didn't offer a official way to connect component to external changing data. The only way you can do is by using useEffect incorrectly.

mmis1000 1y ago

I had do frontend for decades and witness the Jquery => Angular.js => React/Vue (Class) => React/Vue (Hook) transition. And out of them, the react hook is the only one that 'doing it wrong' is easier. A good API interface should have least resistance for the user when doing things correctly. But React Hook almost feels like the complete opposite of this phenomenon. It's complex, comes with tons of foot gun. And yet still get popular? Wondering if there is something other like this exists in the computer history.

skydhash 1y ago
Because it’s very simple. React is only a view layer that promises that your UI will always reflect your state. Bugs is usually when people brings in things that has no place being there. Aka no discipline in separating the view module from everything else.

5Qn8mNbc2FNCiVV 1y ago

The trick is to not worry about useMemo and useCallback because it's rarely an issue unless you have 800 line components or don't compose but rather treat everything as if it was inheritance. I've got pretty sizeable codebases, less than 5 useEffects ever (nowadays I only have one for a single location where I need to manually poll, the rest is useSyncExternalStore) and I only do useMemo for tables. Compiler is just an additional performance improvement that's "free" and at least the compiler doesn't make it harder to understand how your code executes because it just works

pjmlp 1y ago

React is the Git of UIs, the Vulkan, or whatever example you feel more apt for its ways of working, and changes across versions. Unfortunely, it has won the mindshare game, in many SaaS products I tend to work on, they only provide React and by extension Next.js based SDKs, if I want to use vanila.js, Angular, Vue or whatever, it is on me to make it work, if it is possible at all, given the product expectations on its extension points. Eventually the "everything must be React" wave is going to pass, hopefully.