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.