From Angular to React - What Actually Changed

angular
react
frontend

I spent almost three years writing Angular at BNP Paribas. Angular 9, to be precise, full of services, RxJS pipes, modules, and a very clear opinion on how you should structure your application. Then I switched roles internally, and the new stack was React with TypeScript.

People love to compare these two online as if it's some holy war. In practice, the switch was less dramatic than the internet would have you believe, but there were a few things that genuinely caught me off guard.

The State Management Shock

This was the big one.

In Angular, state management felt natural. You'd create a service, inject it wherever you needed it, and use BehaviorSubjects or other RxJS primitives to manage and share state across components. The data flowed through observables, and the framework gave you a clear mental model for where state lived and how it moved.

// Angular: a service manages state, components subscribe
@Injectable({ providedIn: 'root' })
export class DocumentService {
  private documents$ = new BehaviorSubject<Document[]>([]);
 
  getDocuments(): Observable<Document[]> {
    return this.documents$.asObservable();
  }
}

Then I opened a React codebase and found useState, useEffect, useContext, useReducer, useMemo, useCallback, and that was just the built-in stuff. On top of that, there was a whole debate about whether to use Redux, Zustand, Jotai, or just React Context.

In Angular, the framework made the choice for you. In React, you make every choice yourself. That's both the selling point and the problem.

I went full hooks. No RxJS, no observables. Cold turkey. It wasn't because hooks are better or worse, but because trying to mix paradigms felt like fighting the framework. React wants you to think in terms of component state and effects, not in terms of streams. Once I accepted that, things clicked.

What I Actually Prefer About React

Here's the thing I didn't expect: I like React's simplicity.

Angular components come with a TypeScript file, an HTML template, a CSS file, and a spec file. You have decorators, lifecycle hooks with specific names (ngOnInit, ngOnDestroy, ngAfterViewInit), and a module system that wires everything together. There's a lot of ceremony before you get anything on screen.

React components are just functions. They take props, they return JSX, and that's it. Need state? Call useState. Need a side effect? Call useEffect. Want to share logic? Write a custom hook. There's no class hierarchy, no decorators, no module declarations.

// React: it's just a function
function DocumentList({ teamId }: { teamId: string }) {
  const [documents, setDocuments] = useState<Document[]>([]);
 
  useEffect(() => {
    fetchDocuments(teamId).then(setDocuments);
  }, [teamId]);
 
  return (
    <ul>
      {documents.map(doc => <li key={doc.id}>{doc.name}</li>)}
    </ul>
  );
}

Is this always better? No. For large enterprise applications with big teams, Angular's opinions prevent a lot of "how should we structure this?" debates. But for moving fast and keeping things lean, React gets out of your way in a way Angular never did.

The Ecosystem Advantage Is Real

In Angular, if you needed HTTP calls, you used HttpClient. Forms? ReactiveFormsModule. Routing? @angular/router. Testing? Angular's TestBed. It's all built-in, it all works together, and the documentation covers it.

In React, you choose everything. HTTP? Maybe fetch, maybe axios. Forms? React Hook Form, Formik, or just roll your own. Routing? React Router. I considered Next.js but we wanted a pure frontend since the backend logic needed to be Python because of its AI library ecosystem.

At first, this felt overwhelming. But once you settle on your stack, the React ecosystem is genuinely massive. Whatever you need, someone's already built it, documented it, and there are fifteen blog posts about it. Need to animate something? Framer Motion. Need a headless component library? Radix.

The Angular ecosystem exists too, but it's smaller. Some libraries feel abandoned. The community gravitates toward React, and that shows in the quality and variety of what's available.

What I Actually Miss

Modules and Lazy Loading

This is the one thing I think Angular handled more cleanly. Angular's module system let you group related components, services, and routes together and lazy-load entire feature modules effortlessly:

// Angular: lazy load an entire feature
const routes: Routes = [
  {
    path: 'documents',
    loadChildren: () =>
      import('./documents/documents.module')
        .then(m => m.DocumentsModule)
  }
];

The boundary was clear. Everything inside that module was self-contained, and the router handled code splitting automatically.

In React, you can absolutely do code splitting with React.lazy and Suspense. But the organizational boundary isn't as clean. There's no equivalent of "this module encapsulates these components, these services, and these routes." You have to create that structure yourself through folder conventions, and not everyone on the team will agree on what that looks like.

Things That Don't Matter As Much As People Think

TypeScript support. Both are excellent with TypeScript. Angular was built for it, React has caught up entirely. This is not a differentiator anymore.

Performance. For the kind of internal tools and platforms I build, neither framework has ever been the bottleneck. The database query or the API call is always the slow part, never the rendering.

Learning curve. Angular has a steeper initial curve because there's more to learn upfront. React has a different kind of curve. It's easy to start, but you'll spend weeks figuring out the right patterns and libraries for your specific use case. Pick your poison.

What I'd Tell Someone Making the Switch

Don't try to write Angular in React. I see people creating "service" classes in React, trying to replicate dependency injection with context providers, or reaching for RxJS because it's familiar. Don't. Learn the React way of doing things: hooks, composition, custom hooks for shared logic. Fight the urge to recreate what you know.

Accept the choice paralysis, then move on. Yes, you'll spend a day deciding between state management libraries. Pick one, commit to it, and revisit in six months if it's not working. The wrong choice made quickly is better than no choice made slowly.

Your Angular experience is more valuable than you think. Understanding component architecture, lifecycle management, dependency injection patterns, and reactive programming doesn't go away just because the syntax changed. I found that my Angular background made me a better React developer because I already understood why certain patterns exist. I just needed to learn the new how.

The Honest Take

Neither framework is objectively better. Angular gives you structure and opinions, which is valuable when you have a large team and want consistency. React gives you freedom and a massive ecosystem, which is valuable when you want to move fast and pick the best tool for each job.

I went from Angular to React and I'm happy with the switch. But if my next role used Angular again, I wouldn't complain. The fundamentals transfer. The rest is syntax.


Switched stacks recently? I'd be curious to hear what surprised you the most. Hit me up.