"Friends don't let friends use React" were the first words in this post.
🚨 Friends don’t let friends use React. 🚨
We all know that every line of code you add today is just a future liability waiting to haunt you. Technical debt is real, and once you’re in deep, there’s no easy way out.
Now, imagine your friend maxing out their credit cards on overpriced junk, living that "buy now, cry later" lifestyle. Would you just stand by and let it happen? Of course not! You’d step in, shake them by the shoulders, and say, “Think about your future!”
So why is it any different when you see a fellow developer swiping their React credit card, installing package after package, drinking the hook-flavored Kool-Aid, and convincing themselves that yet another state management library is the answer to all their problems?
It starts small, just a little JSX here, a sprinkle of useEffect there. Then, before they know it, they’re lost in dependency hell, buried under 4,187 npm packages that all mysteriously break after a minor version update.
Will you step in? Will you be the friend who saves them from themselves? Or will you let them spiral into an endless cycle of over-engineered component hierarchies?
React may be seductive, but it’s a one-way ticket to regret. Intervention starts with you.
⚛️ React. Not even once.
It didn't catch me off-guard, given this was yet another blanket statement toward a library (in this case, React).
I don't involve myself in heated conversations, yet I was compelled to reply to the post with:
A better argument here would be, "use a framework, not a library" -- it never has anything to do with React and everything to do with not having opinion. When there is only opinion, is there no one right way to do something.
To my surprise, my reply had a follow-up from another naysayer:
Michael Hertzberg: Such horse sh*t! All subjective opinions are validated by objective reality in the end. They don’t exist in isolation. Reality tells us which opinions yielded the most productivity and the simplest code. Definitely not React. At every React codebase I joined over the years, it was absolutely horrendous compared to other technology codebases. Opinions CAN BE wrong when they miss the target of doing client work with the most productivity and maintainability and at the lowest cost and time to deliver. I currently use a technology that can implement React Frontend work in half the time, easily, with the code being much more readable by everyone. It’s not even close. React sucks. All smart software engineers know that already.
Without any quick judgment on my part given their emotional response, I was eager to give an emotional response; however, I took a moment to address everything, instead of throwing a bunch of unproductive streams of consciousness. Here was my response:
[Redacted], that's a strong take. but, you're presenting your own subjective experience as "objective reality," which is exactly what you're criticizing.
React is just a UI library. It doesn't enforce architecture or patterns, which is why you see such wildly different React codebases; my point about opinions vs. frameworks.
The "horrendous" codebases you encountered weren't predetermined by React itself - they were the result of architectural choices, team dynamics, and project constraints. Maybe you worked on "horrendous" teams.
You mention using a technology that's 2x more productive for you -- that's awesome! Different tools work better for different people and projects. But declaring "all smart engineers know React sucks" doesn't reflect reality, it just dismisses the valid experiences of countless skilled devs who find value in it.
My original comment wasn't defending React, it was pointing out that libraries without opinions naturally lead to more diverse (and sometimes messy) implementations. That's a tradeoff, not a failure.
React is fine for smart people if they want to.
What do you think?
Top comments (5)
The "crime" of React is that it has been made an equation between "modern web development" and React. So everyone jumps the train, without deeper knowledge and understanding, and starts creating messy implementations that are probably pain to maintain.
I don't like React. I am team Vue. I prefer its Composition API to othet forms of reactivity and its templates over cryptic JSX. And I think there is no real reason for prefering React unless "I have a special case and there is no utility library for the other technology yet".
On the other hand - I started using Vue utterly wrong and my first big project is a mess thanks to its poor design. It works, but it is complicated and nearly impossible to change now. So I can imagine others do the same in React and creating reasons for hate.
I'm in the progressive enhancement camp, so any library has to warrant a good reason to be pushed to the users. Why use a library when you can use build-in features?
But on the server side I have less of a problem with React, because then it is going to be used as a templating engine. And for templating engines i take the pragmatic route, the one with the most users wins.
So I agree with your conclusion, all libraries have a purpose. Use them wisely.
PS: I don't consider myself to be a smart person.
While it is in fact, a multitude of factors that make code great or horrendous, it is a fact that React doesn't help. It was great 8 years ago. Now it is showing its age. It cannot keep up with the new kids on the block.
Use a framework? Are you saying that NextJS is THE solution? That simply by moving to Next or whatever all is good and well? I disagree. Not because frameworks are not better. They are probably better than React (the library) alone. But other frameworks such as Svelte do a lot better.
So yes, there's a multitude of inputs to the (horrendous) outcomes in the React world, but certainly React doesn't help.
All taken in, I agree: Friends don't let friends use React.
You’ve nailed it. The problem is rarely the toolset—whether it’s Angular, React, Vue, or even the language itself. It’s about the architecture and the discipline behind the implementation.
Common Pitfalls:
Monolithic Coding – Everything jammed together in a way that resists scaling and maintainability.
Dependency Hell – Packages and frameworks spreading across the entire codebase, making updates or refactoring a nightmare.
Ignoring SOLID Principles – Without Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, code inevitably becomes rigid and difficult to extend.
DRY Violations – Redundant, copy-pasted logic leading to inconsistencies and technical debt.
Misuse of Modules – Dumping everything into giant service files instead of properly encapsulating concerns.
Ignoring SRP During Refactoring – Breaking something apart just for the sake of it, rather than maintaining clear, single-purpose components.
The Long-Term Perspective
It’s not just about getting it working today; it’s about maintaining it five years from now. Will future developers (or even your future self) be able to read, debug, and extend the code without unraveling a mess?
The snakes in the grass?
Short-term hacks
Spaghetti dependencies
Over-engineering without pragmatism
Under-engineering that ignores scalability
The best developers aren’t just coders; they’re architects who build for the future.
I have seen some terrible Vue code in my time lol. Understand JS, understand your tools and frameworks and what they're doing with JS, understand the problems you're trying to solve - then regardless of the FE framework you use you will write good software.