"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 ...
For further actions, you may consider blocking this person and/or reporting abuse
People who get this upset about other people using a different tool than what they consider the "best" tool, just expose themselves as terrible developers completely stuck in a singular mindset of black and white 🤷
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.
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.
The original post on LinkedIn tells me someone is mining for comments and reactions to boost their profile. And it looks like (from that screenshot showing ~450 interactions) it worked. It doesn't mean they're right. They just want to be loud on LinkedIn for loudness sake - that's what moves the needle on social media right now.
And React is the big kid on the block. Easy to take shots at the biggest - just ask Patriots or Chiefs fans what other people say about them right now.
If you like React, use it. If you don't like React, don't use it, don't build projects with it, and apply to jobs that use something else.
I agree with you. I think as long as you learn the fundamentals (JavaScript and basic logic with it) first, React is awesome. By itself, React can be hard to use for the web, especially doing routing and APIs, which is why frameworks like Next.js exist.
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.
There are only two types of frontend frameworks/libraries.
The ones that almost no one uses and the ones that are complained about.
All your points are fair and square. Haters gonna hate.
Really enjoyed your take on React in this post. Your thoughtful dismantling of common criticisms not only sheds light on the framework's practical benefits but also helps bridge the gap between skeptics and its loyal fans. I particularly appreciated how you highlighted React’s flexibility and ease of learning, which really counters the naysayers' arguments. Keep up the great work! 👍
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.
Thanks for the reply José.
I appreciate your perspective, though I see you share a similar view with the original post. When you say "it is a fact that React doesn't help," you're presenting a personal viewpoint as established fact. This implies React actively contributes to poor code quality rather than simply being outdated as you suggest.
Technical vocabulary can create confusion in these discussions. My "use a framework" comment wasn't specifically about Next.js being THE solution. There are many frameworks that add opinions on top of React -- Next.js, Remix, Gatsby, etc. -- or completely different approaches depending on project needs.
You're comparing across different categories. Svelte is a component framework, React is a library. Even Svelte still needs SvelteKit to provide SSR, routing, etc. -- just like React can leverage Next.js for those features. This actually supports my original point about frameworks vs libraries.
While Svelte and other newer frameworks certainly have their advantages, whether these translate to better application architecture or code quality depends entirely on the specific project needs and how teams implement them.
When you say "React doesn't help" -- the issue isn't React itself, it's using React without additional structure and opinions. That was my entire point. The problem isn't the tool; it's how teams implement and organize around it.
Ultimately, use what works for you and your team. Different projects have different needs. But presenting personal experience as universal truth doesn't help others make better technology choices for their specific context.
Apologies. I was trying to go soft on React. If I gave you the impression that I was implying just a problem of being outdated, that's my bad. React SUCKS big time.
It is true that adding on top of React helps, but up to what point? After all, the base is React. React is inherently faulty. The entire tower you build is, therefore, faulty at its core.