Comment by alisonatwork | Hacker News Reader

Comment by alisonatwork | Hacker News Reader

Parent Full thread

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.

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

I feel the same way about vue switching to hooks. What is the exact problem we're solving?

Hooks were introduced in early 2019, they're hardly bleeding edge

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.

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.

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.

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.

> *Treating one big function handling 10 different scenarios is not what I would call functional components, much less simpler in nature.

That’s an antipattern. Like the 200 lines function in imperative or the god class in OOP.

Your components should be small and composable. Before directly using the standard hooks in the components, you should think first if it would not better to write a custom one. Scenarios should be handled by custom hooks and component should just get data from them. If you cannot test scenarios apart from your views and vice-versa, you’re doing it wrong

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.

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.

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.

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.

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.

Reply on news.ycombinator.com