React vs Angular: Differences and When to Pick Each

React is a JavaScript library for building user interfaces, and Angular is a complete framework for building web applications. With React you write components as functions that return JSX and pick separate tools for routing, forms and data; with Angular you write TypeScript classes with HTML templates and get routing, forms, an HTTP client and dependency injection in the box. Here is the same counter in both.

import { useState } from 'react';

export default function App() {
    const [count, setCount] = useState(0);

    return (
        <button onClick={() => setCount(count + 1)}>
            Clicked {count} times
        </button>
    );
}

The Angular version of that component:

import { Component, signal } from '@angular/core';

@Component({
    selector: 'app-counter',
    template: `
        <button (click)="increment()">Clicked {{ count() }} times</button>
    `,
})
export class CounterComponent {
    count = signal(0);

    increment() {
        this.count.update((n) => n + 1);
    }
}

The ideas match one to one: React's useState(0) is Angular's signal(0), onClick={...} is (click)="...", and {count} is {{ count() }}. The difference is where the code lives: one function returning markup in React, a class plus a template string in Angular.

Library vs framework

This is the difference that drives most of the others. React covers rendering and component state. Everything else is your choice:

• Routing: React Router, TanStack Router, or a framework's file-based routes.
• Data fetching: fetch in an effect, TanStack Query, or a framework's loaders and server components.
• Forms: plain controlled inputs, React 19 form actions, or React Hook Form.
• Global state: context, Zustand, Redux Toolkit, Jotai.

Many teams skip most of those choices by starting from a React framework such as Next.js or React Router in framework mode, which bundles routing, data loading and server rendering.

Angular makes those choices for you: @angular/router, reactive and template-driven forms, HttpClient, dependency injection, a testing setup and the ng CLI that generates components and services. Every Angular project looks broadly the same, which is a common reason large organizations choose it. The cost is a bigger surface to learn and less freedom to swap a piece out.

JSX vs templates

React components return JSX, which is JavaScript. Conditions are && or a ternary, lists are .map(), and anything you can do in JavaScript you can do in markup. Angular templates are HTML with their own syntax: @if, @for with track, [property] bindings, (event) bindings and {{ }} interpolation. Templates keep markup and logic visibly apart; JSX keeps them in one place and gives you the full language. Here is a filtered list, the second feature to compare.

import { useState } from 'react';

const fruits = ['Apple', 'Banana', 'Cherry', 'Grape', 'Mango', 'Peach'];

export default function App() {
    const [query, setQuery] = useState('');

    const visible = fruits.filter((f) =>
        f.toLowerCase().includes(query.toLowerCase())
    );

    console.log('render, query =', JSON.stringify(query));

    return (
        <div>
            <input
                value={query}
                onChange={(e) => setQuery(e.target.value)}
                placeholder="Filter fruit"
            />
            <ul>
                {visible.map((fruit) => (
                    <li key={fruit}>{fruit}</li>
                ))}
                {visible.length === 0 && <li>No match</li>}
            </ul>
        </div>
    );
}

Type an into the box and watch the console: the whole function runs again on every keystroke, and visible is simply recomputed. The same component in Angular, with the template in its own file:

import { Component, computed, signal } from '@angular/core';

@Component({
    selector: 'app-fruit-filter',
    templateUrl: './fruit-filter.component.html',
})
export class FruitFilterComponent {
    fruits = ['Apple', 'Banana', 'Cherry', 'Grape', 'Mango', 'Peach'];
    query = signal('');

    visible = computed(() =>
        this.fruits.filter((f) => f.toLowerCase().includes(this.query().toLowerCase()))
    );
}

<input #box [value]="query()" (input)="query.set(box.value)" placeholder="Filter fruit" />
<ul>
    @for (fruit of visible(); track fruit) {
        <li>{{ fruit }}</li>
    } @empty {
        <li>No match</li>
    }
</ul>

In Angular, computed declares that visible depends on query, so Angular knows which template reads it and recomputes visible only when query changes. In React there is no declaration: the component re-runs and recomputes. The key={fruit} in React and track fruit in Angular do the same job, telling the framework which list item is which.

JavaScript first vs TypeScript first

React is plain JavaScript with JSX, and TypeScript is an option you add (npm create vite@latest my-app -- --template react-ts). Most new React projects do add it, but you can learn React without knowing types. Angular is built for TypeScript: decorators, dependency injection and the template type checker all assume it. If your team already writes typed code, that is a non-issue; if you are new to programming, it is one more thing to learn at once. The React with TypeScript page shows how typing works on the React side.

Data flow and change detection

Both pass data down through inputs (props in React, input() or @Input() in Angular) and send events up through callbacks (functions passed as props in React, output() or @Output() in Angular). The difference is how each one notices a change.

React treats state as immutable snapshots. You call a setter with a new value, React re-runs the component function, compares the new JSX with the old, and patches the DOM. Nothing is tracked automatically: the render function is the dependency graph. That is simple to reason about, and the cost is that you sometimes add memo, useMemo or useCallback (or let the React Compiler add them) to skip work.

Angular historically used Zone.js to detect any async event and then checked the component tree for changed bindings. Modern Angular is moving to signals: signal, computed and effect track which values each template reads, so Angular checks only the components whose signals changed, and recent versions can run without Zone.js entirely. Angular templates do not re-run a whole function on each change the way React components do.

In day-to-day code the two feel closer than the mechanics suggest: you hold state, derive values from it, and the screen follows.

State management

In React, local state is useState or useReducer, shared state is lifted to a parent or put in context, and app-wide state often lives in a small store library. In Angular, local state is signals on the component, and shared state usually lives in a service that is injected wherever it is needed; dependency injection is Angular's built-in answer to "how do two distant components share data". NgRx exists for teams that want a Redux-style store. React has no dependency injection system; context fills a similar role.

Comparison table

Learning curve

React is faster to start. A beginner who knows JavaScript can build something real after learning components, props, state and effects, and the what is React page covers the whole idea in a few minutes. The learning moves later: you have to choose a router, a data fetching approach and a form strategy, and different React codebases make different choices.

Angular has a steeper start: TypeScript, decorators, templates, signals, dependency injection, the router and forms modules, and RxJS for some APIs. Once you know it, though, every Angular project uses the same pieces in the same way, so moving between projects is easier.

When to pick which

Pick React when:

• You want a small core and the freedom to choose the rest, or you want a framework like Next.js for server rendering and file-based routes.
• You plan to build mobile apps as well, where React Native reuses the same component model.
• The team is mostly comfortable in JavaScript, or you are learning front-end development and want the shortest path to a working app.

Pick Angular when:

• A large team needs one standard structure across many projects, with fewer architecture decisions to argue about.
• You want forms, HTTP, routing and dependency injection maintained together by one team, upgraded together by the CLI.
• The team already writes TypeScript and likes class-based services and clear separation between template and logic.

Both are mature, widely used in production, and good for a career. The skills transfer: components, one-way data flow, derived state and reactive updates are the same ideas in both.