Some time ago I had opportunity to look into the code of AirBnb frontend, written in React... and it was nightmare. I have PTSD to this day. It was huge monorepo project with ton of components, embedded in one another, without clear logic or structure behind them. Not even clear separation between presenters and containers. I mean, there were some attempts to separate logic from presentation, however, it was not clear from project's structure. There were hundreds of components all in one folder.
To be completely honest with you - I never liked React, so I might biased. But let's dive deeper on why is that in the first place.
The beauty and the beast
Even though I hate it, I can see the appeal. You know a little bit of html, and you know little bit of javascript - you are good to go. It is great rendering engine (!) if you want to move fast. And with the right use case and right architecture it can be very easy to manage, and iterate upon. Basically if your programming experience is purely frontend, little bit of HTML, CSS and JS, than React simply builds upon what you already know.
import React from 'react';
const HelloWorld = () => {
return (
<div className="flex flex-col items-center justify-center min-h-screen bg-gray-100">
<h1 className="text-4xl font-bold text-blue-600 mb-4">Hello, World!</h1>
<p className="text-lg text-gray-700">Welcome to your React application.</p>
</div>
);
};
export default HelloWorld;
Problem comes with complexity. Every project large enough comes through complexity hell. The true test of great technology comes with ease of introduction to new users. This applies both to user experience (UX), and developer experience.
The main problem with React though, is that it does not enforce good architecture from beginning. There is no clear separation of concerns, and logic is mixed with presentation.
I can already hear voices: "there is container/presenter pattern! there is redux/jotai/mobx etc!"
Yes, there is, but it's not enforced standard. It's just pieces of libraries, spread apart without clear implementation guidelines. And unless you end up in greenfield project, you are going to regret it at some point. Fortunately someone had an idea how to rectify that.
The Next(js) React
Clearly Vercel had great idea with it's meta-framework because it solves majority of problems with react. If Express and React had a baby, it would be Next.js. It has folder-based routing, clear project structure, server side rendering and possibility to create server endpoints.
Wait... folder-based routing and server endpoints? I have flashbacks...
<?php
include('pages/'.$_GET['route'].'.php');
?>
Oh.... Now it all makes sense. No wonder server-side react have the same issues: exposing secrets, unused endpoints.
But let's be honest: next.js was created to promote vercel, because were all these noob saas js developers will go with their app most likely?
At lest PHP since version 7 can be called high-level, especially when using with Laravel or Symfony. And PHP is not trying to take over native apps.
React Native
Like taking over the web was not enough. With electron becoming so bloated, and cross-platform mobile apps is basically "killing two stones with one bird" we definitely needed JS solution for that. The good thing is, that any company now can slap Frontend Dev to this task, order them to make mobile app, and call it a day. Great idea on paper. Another nightmare fuel to add if for some reason your mobile app and web app is the same codebase. Oh wait, code base diverges? Let's put couple of if statements and call it a day. It's nice to talk about success stories like "X - formerly Twitter" (we know!) or several Microsoft use cases (I don't remember which ones though tbh). But, boy oh boy, I bet those developers are doing speedrun to burnout.
React Ecosystem
Did you know you can also compose emails and create pdf's using react? Technically you can slap react on your cli as well! Why use go, rust, or even bash when you can use react!
Every language, framework or library becomes trashy if you use it long enough. But let's be honest do you really need react in cli? Ok, I admit, react on discord is pretty neat, and that is something I can see myself using for such case.
The reason for that is that discord bot, even fairly feature-full wouldn't come close to behemoth of a system you can expect in big tech companies. Anything bigger then that, with multiple people in the team and couple of years maintenance cycle, and react goes out of window, unless you start using microfrontends from the beginning and chunking the systems into smaller pieces. But I rarely see that done early on, and later on becomes too late.
What's the alternative?
I can hear react bros sight audibly when I mention Angular. You knew where this is going. I can even hear accusations in the style of "oh you are backend dev, obviously you gonna choose Angular". Believe it or not, I started on frontend, but I dabbled my hands in backend as well. And I've been fullstack dev for pretty long time already. Now think a bit about it - why is that Angular is so often selected by backend developers? Why is that Java with Spring Boot is still the default on backend corpo world, even when there are newer and faster technologies?
The answer is simple - reliability and predictability. Most backend developers experienced maintaining existing codebase for a long time. And jumping into existing project where you don't need to worry about technology, only the business rules, is way better.
Angular is a framework compared to React. Pure web (browser) technologies were never designed as software development tool to begin with. That's why Angular adopts a lot of solutions that where proven in traditional application development.
It imposes certain standard on developer from the start. Even without conscious architecture and pattern selection, you can be almost sure, that most logic will land in the services, and most rendering will happen in components. Performance-wise it might not be the best option but on the long run? As maintainer you will be frustrated significantly less so then in React. Because React codebase is maintained differently in every company. And under certain threshold it does not matter if app is responsive in 400ms or 200ms. If that matters to you so much... what the hell you are doing in JS?
Did you know that a lot of companies that are established on the market for quite a long time compared to most big tech giants actually prefer Angular? Companies that have more than 20-30 years of history will stick with Java and Angular instead of React or Next.js. Those companies are less volatile to market changes, and prone to lay offs, if you value your stability, don't pursue FAANG or any startup that went big in last 10 years. Maybe with exception to fintech... fintech is crazy town, regardless of how much they are on the market.
Now let me give you my personal recommendations.
Web
Angular - Obviously. Keep in mind, that Angular didn't sit on his ass while others where innovating. Currently modules are not mandatory, components can be standalone. Also you can actually get rid of zone.js and polyfills completely, and use signals instead! That speeds up application considerably.
Meta-framework
Analog.js - If Next.js and Angular SSR had a baby (there is no angular universal anymore). It still uses Angular under the hood, so migration should not be that hard. I think in general it is even better then native SSR, because you don't have to use afterRender and afterNextRender (I might be wrong here, so correct me if I am).
Backend framework
Nest.js - You need backend only approach in Node, and you like Angular / Spring Boot? Well, fret not, Nest.js comes with help. One of the reasons why Angular is so popular among backend developers are "@" annotations that make cross-cutting concerns like dependency injection easy. Nest.js just much like Spring enables such annotations like @Controller in your code. Keep in mind however, because it's backend framework, it does not adopt angular.
Mobile Development
Here we have actually two options, one obvious: Flutter; and one not so obvious: PWABuilder.
PWABuilder - great option if you have website with PWA enabled in Angular or Analog.js. With this tool you can quickly turn your PWA App into Native app, that you can compile and put on Google Play or Apple App Store. But keep in mind it has some limitations.
Flutter - while not much of a standard angular approach, it's way easier to grasp and manage then React Native app. It has little bit less smooth animations than React Native, but overall performance is much better. Great thing about it is that it comes with a lot of ready-to-use Widgets based on Native Apple or Android UI, that you can further customize.
Conclusion
I don't dismiss React altogether. It has it's use cases and overall contribution of this technology to web development is huge. I don't deny that. There is a place for everything. However it has a feature called "brainrot native" that causes average frontend developer to design poorly. And because it's relatively very young technology (official React launch was 2013, Angular.js was 2010) not a lot of devs with years of experience came to it. Nobody coming from jQuery was thinking about big frontend websites outside maybe of Google! Think about it. Who at the time was doing massive frontend websites? Google. Who come up with angular.js? Google. In the meantime 90% of Facebook was running on PHP. That's why they come up with react, because they needed small pieces of website updated with small components, not a whole web app run in the browser. And the architecture of both reflect that.
So take my advice, and go with Angular if you are going to make massive web application that is going to be maintained over the course of several years. Or make a proper f*cking architecture design for your application if you are going with React, so others don't go bald maintaining it.
Top comments (4)
Interestingly, my experience has been completely different. I’ve been a frontend developer for 30 years, and in recent years, I’ve mostly worked on Angular projects. Then, I also got well acquainted with the React platform. Initially, I was very skeptical for subjective reasons, as Angular is generally recognized as the most serious platform for large projects. However, after developing a few React projects, I became so impressed with it that I switched from Angular to React. Developing in Angular started to frustrate me too much because large projects become too incomprehensible due to the use of services, dependency injection, and declaring components in modules. In the HTML code, custom HTML tags are used, and sometimes it’s very difficult to figure out in which module they are implemented (or which module you need to import for the custom HTML tag to work). Even more confusing is the use of directives. A major drawback of Angular is that you cannot extend native HTML components (directives are a lacking solution for many requirements, eg. you cannot extend native element like HTMLInput with some additional props and give it a custom html tag name). Dealing with custom component change events is a nightmare.
React solves these kinds of confusions in a more understandable way. In each component, you import exactly the components you want to use, so it’s always clear which component implements the custom HTML tag in use. It's easy extending native HTML components, and handling property change events is much more simple and flexible.
Also, the use of services in Angular often turns out to be confusing, because you have to define various services in separate modules and then inject them into the constructors of components. Sometimes, you struggle to figure out why you’re seeing a NullInjectorError at runtime (because you forgot to register a specific provider in the module). In React, you don’t have these issues – you simply import the service into the component, and everything is clear. Yes, React does not have built-in patterns for services, but you can just implement them as classes, expose them as static global singletons or similar, and import them wherever needed.
In my experience, an experienced development team that is already familiar with established architectural patterns (for services, components, etc.) can develop a project in React that is generally more transparent, understandable, and easier to develop than in Angular, and, most importantly, performs better with generally smaller bundles. React is often associated with more chaotic projects, but I think that’s because more inexperienced developers choose React (precisely because it’s simpler for basic use), which results in an unorganized project. However, they would create a messy project even if they were building it in Angular.
I agree with the last point - newbies wreck havoc in any project if left unattended.
It looks like you didn't touch Angular for quite some time. However I would like refute some points you discussed:
From your comment I might also assume you didn't had opportunity to work on backend side or used design patterns. Dependency Injection is actually one of the core functionalities that makes Service management or any application wide cross-cutting concerns way easier to manage. If you ever created a container class that holds reference to every service - that already was dependency inversion pattern.
Long story short - what you might consider cons, I consider pros. And reason for that might be because I have different experience and road behind me than you.
Błażej, I’m familiar with all the suggestions and updates you mentioned, as I still actively use the latest versions of Angular. I wouldn’t want to delve into details, and I’m not actually a strong opponent of Angular. I believe that any platform can prove to be superior depending on the specific project needs. Perhaps we've just been working on such different projects that we have somewhat opposite biases at the moment. We might actually agree with each other if we exchanged our projects and found ourselves dealing with different requirements.
What really bothers me in your article is the excessive demonization of React. Although I get the feeling that the article might be written in the heat of an exaggerated emotional reaction and that, deep down, on a reasonable level, you don’t hold such a radical opinion ;)
I really hate React's virtual DOM, I think this is totally a design mistake,
And react hooks also make it difficult to abstract logic when writing super-complex pages.