5 ms·

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,

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
      Apparently we are in the minority, but I find hooks great for DRY and composition. My components can be thin and presentational while the business logic is tucked away in neat little packages. Didn't realize how much I disliked class components and HOCs until hooks showed up. Footguns, learning curve? Sure, but I'll still make that trade.
    - owebmaster 1y ago
      Treating one big function handling 10 different scenarios is not what I would call functional components, much less simpler in nature. React in its current incarnation is the best framework to create unmaintainable code.
- fleebee 1y ago
  You can still write simple, understandable React. All the weird, obscure hooks they have added in the recent years are opt-in and are often better left for library maintainers. You probably don't even need useMemo or useCallback. That's not to say I don't see developers (mis)using them all the time, but that's self-imposed convolution and you can only blame React as a footgun supplier.
  - skydhash 1y ago
    I ise hooks all the time, mostly because I write custom hooks that wraps everything external to my view. Makes for a simpler conponent code.
    - codemonkey-zeta 1y ago
      I agree that this is the approach that keeps react apps simple. The biggest problems I see in react code are giant components that read like this: useState useState useState ... // 20 more useEffect useEffect useEffect ... // 20 more I think a lot of front-end devs don't realize the necessity of custom hooks for composition and modularization. My personal rule is "Never use react hooks (useState, useEffect, etc.) in component code. All react hooks MUST be wrapped by custom hooks." and it makes for MUCH better code: useSomeData useOtherData useMobileView useScrollToTop useInteractionLogging ... // 10 more hooks This is also what makes TanStack so good and popular. It's all just behavior wrapped in hooks.
      - matsemann 1y ago
        This I disagree on. Unless the hook is to be reused, just chuck it in your component where it's actually used. Yeah, it's pretty if you can decompose it cleanly. But if you end up with calling useX, and passing a statement function from that to useY etc, it's just a mess figuring out what's going on. Just chuck it all in the component and skip the abstractions.
        skydhash 1y ago
        For very small local state, I can agree. But if you three or more standard hooks that interact together, it’s worth it to wrap it in a custom hook even if it’s going to be in the same file. The semantics will be clearer and working with the code easier. I much prefer to see useFlashyAnimation than its code in the component.

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
    Apparently we are in the minority, but I find hooks great for DRY and composition. My components can be thin and presentational while the business logic is tucked away in neat little packages. Didn't realize how much I disliked class components and HOCs until hooks showed up. Footguns, learning curve? Sure, but I'll still make that trade.
  - owebmaster 1y ago
    Treating one big function handling 10 different scenarios is not what I would call functional components, much less simpler in nature. React in its current incarnation is the best framework to create unmaintainable code.
fleebee 1y ago
You can still write simple, understandable React. All the weird, obscure hooks they have added in the recent years are opt-in and are often better left for library maintainers. You probably don't even need useMemo or useCallback. That's not to say I don't see developers (mis)using them all the time, but that's self-imposed convolution and you can only blame React as a footgun supplier.
- skydhash 1y ago
  I ise hooks all the time, mostly because I write custom hooks that wraps everything external to my view. Makes for a simpler conponent code.
  - codemonkey-zeta 1y ago
    I agree that this is the approach that keeps react apps simple. The biggest problems I see in react code are giant components that read like this: useState useState useState ... // 20 more useEffect useEffect useEffect ... // 20 more I think a lot of front-end devs don't realize the necessity of custom hooks for composition and modularization. My personal rule is "Never use react hooks (useState, useEffect, etc.) in component code. All react hooks MUST be wrapped by custom hooks." and it makes for MUCH better code: useSomeData useOtherData useMobileView useScrollToTop useInteractionLogging ... // 10 more hooks This is also what makes TanStack so good and popular. It's all just behavior wrapped in hooks.
    - matsemann 1y ago
      This I disagree on. Unless the hook is to be reused, just chuck it in your component where it's actually used. Yeah, it's pretty if you can decompose it cleanly. But if you end up with calling useX, and passing a statement function from that to useY etc, it's just a mess figuring out what's going on. Just chuck it all in the component and skip the abstractions.
      - skydhash 1y ago
        For very small local state, I can agree. But if you three or more standard hooks that interact together, it’s worth it to wrap it in a custom hook even if it’s going to be in the same file. The semantics will be clearer and working with the code easier. I much prefer to see useFlashyAnimation than its code in the component.