This is the second post of my “Software Engineering is broken” series. If you haven’t read the first one, go read at least the introduction to get an idea of where this is coming from. I will sometimes refer to a project of a friend of mine; the introduction is where I describe it.
You should stop using React. In fact, you probably should have never used React in any of the projects you used it on. But before you pull out your sawed-off shotgun and shoot me, hear me out. And keep in mind that a lot of what I’ll say here also applies to other tools like Vue and even Single Page Applications in general, not just React.
React is an impressive piece of technology and it helped push forward the concept of using components for web UIs, which is great.
Unfortunately, it is also bloated, slow, complex, ignores and reinvents foundational web technologies, it completely negates search engine indexing (and, consequently, SEO), and it duplicates the effort to build a web application because it forces you to have two full software development projects - frontend and backend - with all the costs that come along with each one. The vast majority of projects are much simpler than the scenarios React was designed for, and choosing it ends up causing more harm than good.
So why do so many people swear by React?
React probably became popular due to a combination of a great idea (components), and the typical eagerness to adopt technologies from Big & Cool companies, as if these tools were made to solve the same type of problems small companies have. I guess the thought of using a piece of software from a Big & Cool company is too enticing for too many programmers, even if it will make their lives miserable. A lot of people also say that React is “easy,” which is a distorted interpretation of the concept of “easy”, but probably still influenced a lot of junior developers to get into it.
Interestingly, whenever I ask someone about their motives to use React, they don’t really have a concrete reason. Some people are humble enough to admit that “it’s what everyone else was using and I just went with it.” But more often, people adopt a defensive stance and shield themselves behind flawed arguments.
As expected, the agency replied in a very defensive manner and stood by their proposal of using React. Also not surprisingly, they used flawed arguments to defend their choice.
They said, and I quote:
Because we’re talking about the most popular and most used technologies in the market, versus libraries with no expression and no community. This point is important to guarantee that you can find people who can work on the product, even after we deliver it.
This point is actually based on a valid concern and it is indeed something that should usually be taken into consideration when picking a software tool. The idea is that by using something that is popular, there will be more resources available for that tool. Namely, people for hire and community for support. It was one of my main concerns for my friend’s project, because I knew it was not something he had thought about.
But here’s the thing: HTMX, Alpine and Svelte are not libraries “with no expression and no community” - quite the contrary!
Let’s look at Svelte as an example. According to the State of JS survey, Svelte is in the fourth place for awareness and usage (only the three behemoths, React, Angular and Vue ranked higher, which is to be expected). But it comes first in terms of interest, while React comes in fifth place. And Svelte comes in second place in terms of retention, with only 1% point difference from Solid in the first place, while React is in the fourth place.
HTMX may not be as popular as Svelte but anyone who pays attention to the web development world knows that it has been gaining some serious popularity over the past couple of years and people are saying very good things about it.
I obviously didn’t have these numbers in my head when I proposed the alternatives for my friend’s project, and I am no a front-end developer, but I still knew these “facts” - so how come an agency that works in this world every single day, did not?
But that’s not all. Sure, there are more people who know React than people who know HTMX and even Svelte. And if HTMX was a complex beast that required a lot of time to master, I would agree that it would not be a good choice. But as it turns out, HTMX is super simple to use and would have given them everything they needed to build the project.
The big difference here is: in order to work with React, you also have to know HTML & JS, but just because you know HTML & JS, it doesn’t mean you know React.
Think about it as a Venn diagram:
Another popular argument for React, and one that the agency did not forget to include, is that it is very simple.
In my arguments, I said React was too complex for the project. Here’s what they responded:
About complexity, it is dangerous to interpret it that way. In reality, React helps you structure a project in a more robust way that avoids that same complexity. Otherwise, we’ll have a chaotic project without rules for the code structure, and even though it may seem “simpler and lighter,” it will become harder to manage.
They misunderstood my point and were mixing a couple of different topics: code structure, and complexity.
React doesn’t provide any standard code structure. There may be popular ways to organise source code in a React project but that’s by common agreement from the community, not something we can or should attribute to React, and even less something imposed or required by it. A robust code structure will depend, first and foremost, on the developer and good programming principles. React will not do anything for the project structure if the developer doesn’t know what they’re doing. The question is: what is “well structure code?” If we ask this question to 10 developers, we may get 11 different answers - even within the React world. The main point is to follow good principles, and that does not depend on the tools you use.
I fully agree that sometimes it is necessary to add complexity to a project because the benefits justify it. However, it is necessary to keep in mind that the introduction of any tool is always a trade-off between simplicity and functionality: to add the latter, we lose some of the former. This is valid for any line of code, even our own. For this reason, it is only justifiable to add tools to a project when there is a concrete problem for which a given tool is the best solution and brings benefits that outweigh the cost. If the agency could show me concrete problems that React was going to solve in my friend’s project, problems that could not be solved in a simpler way, I’d be the first to tell them to use React - but of course they couldn’t show me any.
Sure, React is simple - if you never work on a serious production-ready project with it. Anyone who has worked seriously with React for some time will have the same opinion: it quickly becomes a headache.
Time and cost
One of the last points the agency made in favour of React was that by not using React, the whole project would take much longer and cost much more.
This was probably the most obvious point showing that they had no clue about what they were doing.
It was also one of the reasons why I mentioned the complexity issue, and why I defend simpler solutions. Any project that involves React will automatically take more time and be more expensive. There’s no way around it because of the complexity point I mentioned, which, obviously, will require more development time and thus, increase the cost.
But, as discussed above, if you have a much larger pool of developers potentially available to continue a project that uses HTMX than you would have for a project that uses React; if there’s no “React tax” caused by all the hype surrounding it; and if you’ll have a much simpler project that will also be much easier to maintain - doesn’t it stand to reason that it will cost much less to not use React?
Performance & Size
React invented the virtual DOM, which was revolutionary for its time. But it can also lead to very slow performance. Not only that, it is like a full application running in your browser.
The library size alone and how much JS code you have to write for your frontend, along with all the stuff you have to include for browser compatibility, polyfills, and
When you’re a developer working on a beefy machine, sure, you don’t notice it, but when you’re a user on a mobile phone or less powerful device, it can easily become apparent how sluggish it is.
Look at GMail and Reddit. The “rich” versions of their UIs, though containing more features than the plain HTML versions, are so much “heavier” and sluggish, especially in older machines. Is it really worth it?
If you can and know how how to set up a Node server, you can use server side rendering to somewhat mitigate this but at that point React loses a lot of its appeal.
I started writing this article about three years ago (yes, I’m a very slow writer), and fortunately, since then, the frontend world seems to have gained some sense and more and more people are speaking up against the insanity of React and SPAs. Some examples:
In fact, you might not even need components at all. If you feel the need to organise your code that way, sure, go for it. If you are working on a complex application and will need to reuse components in lots of places, absolutely, go for it. Need to share components with other projects or teams? Go for it. But if you don’t have a problem that components would solve, you can save yourself some time and pain.
React can be an acceptable choice for some scenarios but people should learn to evaluate the specific needs of the project and weigh the trade-offs before jumping onto the cool kids train. If it solves a specific problem you have that can’t be better solved by another tool, go for it. Otherwise, you’ll be better off with something simpler.