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.
After reading the agency's proposal for my friend's project, I replied suggesting some alternatives that would be better choices, including telling them to not build a Single Page Application. I proposed that instead of React, they could use simpler tools, like plain HTML and Javascript, and enhance it with something like HTMX and/or Alpine.js. After all, the UI for the application was very simple and had no need for React or to be an SPA at all. If they really wanted to use that type of framework and build an SPA, then they could at least go for something like Svelte or Solid. Or even better, use Phoenix Liveview, Ruby on Rails and Hotwire, or even (forgive me) Laravel's Livewire.
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.
Popularity
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.
More importantly, HTMX does not reinvent the wheel or add a ton of new concepts and techniques with subtle exceptions that need to be mastered and remembered; it reuses foundational web technologies, and because of that, anyone who knows HTML and Javascript will be fully up and running with HTMX in a matter of minutes - much, much less than it would take anyone to learn React.
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:
So if the concern here is about being able to hire people to continue working on the project, it would make more sense to use HTMX than React, because surely, there are more developers who know HTML and Javascript than those who know React.
Simplicity
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.
As for the complexity that I mentioned, that's not related to the structure of the code but with the concepts and subtleties that React introduces beyond the foundational web technologies, and that one must master in order to use it properly: routing, virtual DOM, JSX, hooks, class-based components versus function-based components, component life-cycle and all its events that you must understand, state management (there are full courses and several libraries for this part alone), among other things. None of this exists on the foundational web technologies and they are all extra things any developer has to learn if they want to work with React, even if they already know HTML and Javascript. And I'm not even going into the insanity that is brought in by the constantly-changing React and Javascript world, as well as things like Webpack, Babel, Parcel, etc. The real complexity comes from these things, not the code structure.
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.
Update on February, 2024: after more than a year, the agency still has not finished the project, which they initially estimated to take 3-4 months.
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.
It's a fallacy to say that React saves time because the reality is exactly the opposite. React may seem simple for what it proposes and in its basic idea, but it's not simple at all when compared with well-written Javascript or TypeScript, or even something like HTMX.
There's also the not-so-subtle detail of backwards compatibility. Most React releases introduced breaking changes, forcing people to make deep changes or even rewrite their frontend projects. This sounds like the exact opposite of saving time. Compare that to foundational web technologies that were created dozens of years ago and still work unchanged to this date.
Unfortunately, in the Javascript world, hype is everything, and the mass hysteria in favour of React made it a sort of self-fulfilling prophecy. It is very hard to convince its fans that, even thought it's technically impressive, for the majority of projects people work on, it is a bad choice.
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 even CSS-in-JS. Holy hell, you simply wanted to serve a blog page and suddenly you're forcing your users to download megabytes of code! And this is considered normal? How did we get here?
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?
What about when Javascript is unavailable?
Because websites built with React are rendered on the browser, and thus require Javascript code to be executed, if JS is unavailable for some reason, you'll have a few problems on your hands.
First, your SEO will suffer because search engines don't do so well with Javascript, meaning your website won't be properly indexed and thus, your ranking will drop significantly.
Lastly, there are other scenarios where JS may not be available - either by choice, or necessity. And there are perfectly valid reasons for this to happen, like if you're a journalist covering dangerous news and want to do all you can to secure your browser; or when you're using a computer that forcefully configured your browser to disable Javascript; or perhaps you live in a remote location in a third-world country and only have a low-powered device of which you need to conserve the battery; or maybe you simply can and choose to live in a world without JS and disable it altogether because you don't want to be tracked (yeah, it's not enough to fully block tracking but it's something).
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.
The future
I started writing this article about three years ago, back in 2020 (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:
As I mentioned before, the idea of components in the way React implemented it is a good one. Fortunately, we now have many other, better options to use similar components, including in languages other than Javascript.
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.
My first suggestion would be to go back to foundational web technologies and the web platform: HTML, CSS, and lightly sprinkle some plain Javascript to add interactivity where the web platform doesn't provide what you need. There are libraries - not full-fledged frameworks - that can easily add all the functionality you probably need for the vast majority of the projects you will work on.
Start by taking a look at HTMX and Alpine.js. They both allow you to build web applications that are rendered on the server, while still being able to easily modify the UI in reaction to user actions, load data in the background, use websockets and Server Sent Events, etc. And all of this with simple augmentations to the HTML language - no bloated and complex framework required.
If you can use Elixir, Ruby, or even PHP on the backend, try Phoenix Liveview (by far my favourite), Rails and Hotwire, or Laravel and Livewire. These tools allow you to build a reactive frontend, with bi-directional real-time state synchronisation, without having to pay a huge complecity price. Unfortunately, I don't know of an equivalent for Django. There are a few things but they're not part of the framework, require a lot of manual wiring, and are just not as mature as the other ones.
If for some reason you still want to use a more complex JS framework, then try Solid or Svelte. They are much simpler and much more performant than React, Vue, or Angular. There's also Stencil and Lit, which are quite interesting due to being both based on Web Components standards, meaning they work on all modern browsers and are probably more future-proof than other options (then again, who am I kidding? This is the Javascript world, nothing lasts more than two weeks).
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.
Header photo by Lautaro Andreani on Unsplash
Top comments (2)
it is really
bad practice;-)Yes, I agree with you.
It’s good that there are still people who understand that the React is a wrong way.