React vs Angular: differenze e quando scegliere ciascuno

React è una libreria JavaScript per costruire interfacce utente, e Angular è un framework completo per costruire applicazioni web. Con React scrivi i componenti come funzioni che restituiscono JSX e scegli strumenti separati per routing, form e dati; con Angular scrivi classi TypeScript con template HTML e hai già inclusi routing, form, un client HTTP e la dependency injection. Ecco lo stesso contatore in entrambi.

import { useState } from 'react';

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

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

La versione Angular di quel componente:

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);
    }
}

Le idee corrispondono una a una: lo useState(0) di React è il signal(0) di Angular, onClick={...} è (click)="...", e {count} è {{ count() }}. La differenza è dove vive il codice: una funzione che restituisce markup in React, una classe più una stringa di template in Angular.

Libreria vs framework

È la differenza da cui dipendono quasi tutte le altre. React copre il rendering e lo stato dei componenti. Tutto il resto è una tua scelta:

• Routing: React Router, TanStack Router o le route basate sui file di un framework.
• Recupero dei dati: fetch in un effetto, TanStack Query, oppure i loader e i server component di un framework.
• Form: semplici input controllati, le form action di React 19 o React Hook Form.
• Stato globale: context, Zustand, Redux Toolkit, Jotai.

Molti team saltano gran parte di queste scelte partendo da un framework React come Next.js o React Router in modalità framework, che include routing, caricamento dei dati e rendering lato server.

Angular fa queste scelte per te: @angular/router, form reattivi e basati su template, HttpClient, dependency injection, una configurazione per i test e la CLI ng che genera componenti e servizi. Ogni progetto Angular ha più o meno lo stesso aspetto, un motivo comune per cui le grandi organizzazioni lo scelgono. Il prezzo è una superficie più ampia da imparare e meno libertà di sostituire un pezzo.

JSX vs template

I componenti React restituiscono JSX, che è JavaScript. Le condizioni sono && o un ternario, le liste sono .map(), e tutto ciò che puoi fare in JavaScript puoi farlo nel markup. I template di Angular sono HTML con una sintassi propria: @if, @for con track, binding [property], binding (event) e interpolazione {{ }}. I template tengono markup e logica visibilmente separati; JSX li tiene in un unico punto e ti dà tutto il linguaggio. Ecco una lista filtrata, la seconda funzionalità da confrontare.

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>
    );
}

Scrivi an nella casella e guarda la console: l'intera funzione viene eseguita di nuovo a ogni tasto, e visible viene semplicemente ricalcolato. Lo stesso componente in Angular, con il template in un file a parte:

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 dichiara che visible dipende da query, quindi Angular sa quale template lo legge e ricalcola visible solo quando query cambia. In React non c'è alcuna dichiarazione: il componente viene rieseguito e ricalcola. La key={fruit} in React e il track fruit in Angular fanno lo stesso lavoro, dicendo al framework quale voce della lista è quale.

Prima JavaScript vs prima TypeScript

React è JavaScript semplice con JSX, e TypeScript è un'opzione che aggiungi (npm create vite@latest my-app -- --template react-ts). La maggior parte dei nuovi progetti React lo aggiunge, ma puoi imparare React senza conoscere i tipi. Angular è costruito per TypeScript: decorator, dependency injection e il controllo dei tipi dei template lo danno tutti per scontato. Se il tuo team scrive già codice tipizzato, non è un problema; se sei alle prime armi con la programmazione, è una cosa in più da imparare tutta in una volta. La pagina su React con TypeScript mostra come funzionano i tipi dal lato di React.

Flusso dei dati e change detection

Entrambi passano i dati verso il basso tramite input (props in React, input() o @Input() in Angular) e mandano gli eventi verso l'alto tramite callback (funzioni passate come props in React, output() o @Output() in Angular). La differenza è come ciascuno si accorge di un cambiamento.

React tratta lo stato come istantanee immutabili. Chiami un setter con un nuovo valore, React riesegue la funzione del componente, confronta il nuovo JSX con il vecchio e aggiorna il DOM. Nulla viene tracciato automaticamente: la funzione di rendering è il grafo delle dipendenze. È semplice da ragionare, e il prezzo è che a volte aggiungi memo, useMemo o useCallback (o lasci che li aggiunga React Compiler) per saltare del lavoro.

Angular storicamente usava Zone.js per rilevare qualsiasi evento asincrono e poi controllava l'albero dei componenti alla ricerca di binding cambiati. L'Angular moderno si sta spostando sui signal: signal, computed ed effect tracciano quali valori legge ogni template, quindi Angular controlla solo i componenti i cui signal sono cambiati, e le versioni recenti possono funzionare del tutto senza Zone.js. I template di Angular non rieseguono un'intera funzione a ogni cambiamento come fanno i componenti React.

Nel codice di tutti i giorni i due sembrano più vicini di quanto suggeriscano i meccanismi: tieni uno stato, ne derivi dei valori, e lo schermo segue.

Gestione dello stato

In React, lo stato locale è useState o useReducer, lo stato condiviso viene sollevato in un genitore o messo nel context, e lo stato a livello di app vive spesso in una piccola libreria di store. In Angular, lo stato locale sono i signal sul componente, e lo stato condiviso vive di solito in un servizio iniettato ovunque serva; la dependency injection è la risposta integrata di Angular a "come fanno due componenti lontani a condividere dati". NgRx esiste per i team che vogliono uno store in stile Redux. React non ha un sistema di dependency injection; il context ricopre un ruolo simile.

Tabella di confronto

Curva di apprendimento

Con React si parte più in fretta. Un principiante che conosce JavaScript può costruire qualcosa di reale dopo aver imparato componenti, props, stato ed effetti, e la pagina su cos'è React copre l'intera idea in pochi minuti. Lo studio si sposta più avanti: devi scegliere un router, un approccio al recupero dei dati e una strategia per i form, e codebase React diverse fanno scelte diverse.

Angular ha un inizio più ripido: TypeScript, decorator, template, signal, dependency injection, i moduli per router e form, e RxJS per alcune API. Una volta che lo conosci, però, ogni progetto Angular usa gli stessi pezzi nello stesso modo, quindi passare da un progetto all'altro è più facile.

Quando scegliere quale

Scegli React quando:

• Vuoi un nucleo piccolo e la libertà di scegliere il resto, oppure vuoi un framework come Next.js per il rendering lato server e le route basate sui file.
• Hai in programma di costruire anche app mobile, dove React Native riutilizza lo stesso modello a componenti.
• Il team si trova bene soprattutto con JavaScript, oppure stai imparando lo sviluppo front end e vuoi la strada più breve verso un'app funzionante.

Scegli Angular quando:

• Un grande team ha bisogno di un'unica struttura standard su molti progetti, con meno decisioni architetturali su cui discutere.
• Vuoi form, HTTP, routing e dependency injection mantenuti insieme da un unico team, e aggiornati insieme dalla CLI.
• Il team scrive già TypeScript e apprezza i servizi basati su classi e una separazione chiara tra template e logica.

Entrambi sono maturi, molto usati in produzione e validi per una carriera. Le competenze si trasferiscono: componenti, flusso dei dati a senso unico, stato derivato e aggiornamenti reattivi sono le stesse idee in entrambi.