Svelte o React: quale scegliere davvero

Hai provato Svelte, hai scritto la metà del codice e il risultato pesava un terzo. Poi guardi le offerte di lavoro, guardi quante librerie esistono per React, e ti chiedi se hai scelto lo strumento migliore o quello che ti farà perdere tempo. La risposta onesta non è la stessa per tutti. In questo articolo trovi il confronto a due nel dettaglio: cosa cambia davvero, quanto codice scrivi, come si gestisce lo stato, e dove sta il vero motivo per cui la maggioranza sceglie React.

Il confronto ad alto livello tra i tre grandi è in React, Vue o Angular. Qui si scende in profondità su due soli.

La differenza di fondo

React è una libreria che viaggia insieme alla tua applicazione e a tempo di esecuzione capisce cosa aggiornare; Svelte è un compilatore che quel lavoro lo fa prima, in fase di build, e spedisce al browser solo il risultato.

Tutto il resto discende da questa riga. Il concetto è spiegato per esteso in cos'è Svelte; qui interessa cosa comporta quando devi scegliere.

Compilatore contro runtime: dove il vantaggio esiste e dove si assottiglia

Il vantaggio esiste, e sta nel codice che non spedisci. Un'applicazione React porta con sé React stesso: un programma che a ogni cambiamento di stato ricostruisce una descrizione della pagina e la confronta con la precedente. Svelte quel programma non ce l'ha, perché il compilatore ha già deciso quale nodo aggiornare. Su una pagina piccola la differenza è netta: decine di kilobyte in meno da scaricare, analizzare ed eseguire, e il costo che pesa di più non è il download ma l'esecuzione — che si sente su telefoni economici molto più che sulla tua macchina.

Dove si assottiglia. Il runtime di React è un costo fisso: lo paghi una volta e non cresce. Il codice generato da Svelte cresce invece con il numero di componenti. Su un'applicazione con duecento componenti quel risparmio costante pesa proporzionalmente molto meno, e le due curve si avvicinano.

E soprattutto: il framework non è quasi mai il collo di bottiglia. Immagini non ottimizzate, query lente, script di terze parti che bloccano la resa pesano ordini di grandezza più della scelta tra React e Svelte. Se il tuo sito è lento, guarda prima come velocizzare un sito web e i Core Web Vitals.

Il punto onesto: il vantaggio di peso è reale ma di partenza, non una superiorità automatica, e conta davvero solo in alcuni scenari — che vedremo alla fine.

Quanto codice scrivi per la stessa cosa

Qui la differenza non è discutibile, perché si conta. Prendiamo un contatore con un valore derivato.

React:

import { useState } from "react";

export default function Contatore() {
  const [conteggio, setConteggio] = useState(0);
  const doppio = conteggio * 2;

  return (
    <div>
      <p>
        {conteggio} — il doppio è {doppio}
      </p>
      <button onClick={() => setConteggio(conteggio + 1)}>Incrementa</button>
    </div>
  );
}

Svelte:

<script>
  let conteggio = $state(0);
  let doppio = $derived(conteggio * 2);
</script>

<p>{conteggio} — il doppio è {doppio}</p>
<button onclick={() => conteggio++}>Incrementa</button>

Le differenze concrete: niente coppia valore/funzione di aggiornamento (scrivi conteggio++ e basta), niente import, niente componente da dichiarare, nessun contenitore messo lì solo perché serve un nodo radice.

La forbice si allarga sui moduli. In React ogni campo controllato vuole value e onChange scritti a mano. In Svelte è bind:value:

<script>
  let form = $state({ nome: "", email: "" });
</script>

<input bind:value={form.nome} />
<input bind:value={form.email} type="email" />

Su quindici campi la differenza si sente: è codice ripetitivo in meno da scrivere, leggere e sbagliare.

Contropartita onesta: meno codice significa anche meno esplicito. Il legame a doppio senso di bind: nasconde il flusso dei dati, e quando un valore cambia senza che tu capisca chi l'ha toccato, di solito la colpa è lì.

Lo stato: rune contro hook

Questa è la differenza che si sente di più nell'uso quotidiano, più del peso del bundle.

In React lo stato vive negli hook, che hanno regole: solo al livello alto del componente, mai dentro condizioni o cicli, perché React li identifica per ordine di chiamata. Poi c'è useEffect, e con lui l'array delle dipendenze — la fonte di gran parte dei bug in React:

useEffect(() => {
  caricaDati(userId, filtro);
}, [userId]); // filtro dimenticato: l'effetto non si riesegue quando cambia

Dimentichi una dipendenza e ottieni dati vecchi. Ne metti una di troppo, o un oggetto ricreato a ogni resa, e ottieni un ciclo infinito. Servono un plugin di ESLint per accorgersene e useCallback per stabilizzare i riferimenti — che a sua volta ha il proprio array di dipendenze.

In Svelte questo problema non esiste, e non perché sia stato risolto meglio: non si pone proprio. Le rune tracciano le dipendenze automaticamente, leggendo cosa viene letto durante l'esecuzione.

<script>
  let userId = $state(1);
  let filtro = $state("tutti");

  $effect(() => {
    caricaDati(userId, filtro); // entrambe tracciate, senza dichiararle
  });
</script>

Niente array da tenere allineato, niente plugin del linter che ti corregge. E il capitolo memorizzazione — memo, useMemo, useCallback — semplicemente non c'è: $derived ricalcola solo quando serve.

Le rune funzionano anche fuori dai componenti, in un file .svelte.js: la logica condivisa è una funzione normale, non un hook con le sue regole. In React lo stato condiviso tra componenti distanti richiede quasi sempre una libreria (il panorama è qui); in Svelte spesso basta esportare un oggetto con uno $state dentro.

Va però detto che React si è mosso. Il suo compilatore rende superflua buona parte della memorizzazione manuale e i Server Component spostano logica fuori dal browser: la distanza si riduce, ma non sparisce, perché le regole degli hook e l'array delle dipendenze restano parte del modello.

Ecosistema e mercato del lavoro

Questa è la ragione vera per cui si sceglie React, e non ha senso girarci intorno.

L'ecosistema non è "più grande": è di un altro ordine di grandezza. Ti serve un editor di testo ricco, una griglia dati, un calendario con fusi orari, l'SDK di un servizio di pagamento. Per React esistono tre opzioni mature per ognuna. Per Svelte spesso esiste qualcosa: a volte ottimo, a volte mantenuto da una persona sola che l'anno scorso ha cambiato lavoro.

Trovare risposte è diverso. Per ogni problema in React ci sono dieci discussioni e una risposta accettata. In Svelte c'è la documentazione — ottima — e poi il silenzio sul caso strano capitato a te. Anche gli assistenti di codice conoscono React molto meglio, e con Svelte 5 peggiora: metà del materiale usa ancora la sintassi vecchia.

E poi il lavoro. In Italia le offerte per React sono la maggioranza schiacciante del frontend; quelle per Svelte si contano. Se stai imparando per essere assunto, questo dato pesa più di ogni considerazione tecnica di questo articolo. Vale anche al contrario: se devi assumere, trovi decine di persone che sanno React e quasi nessuna che sa Svelte.

Non è un argomento sulla qualità. Svelte è tecnicamente ottimo: semplicemente la qualità tecnica non determina cosa viene adottato, lo determinano l'inerzia e la disponibilità di persone.

La tabella

	React	Svelte
Natura	Libreria, lavora a runtime	Compilatore, lavora in build
Aggiornamento DOM	Confronto col DOM virtuale	Diretto sul nodo
Peso iniziale	Runtime + codice app	Quasi solo codice app
Peso su app grandi	Costo fisso, non cresce	Cresce coi componenti: divario ridotto
Righe per la stessa cosa	Di più	Di meno, in modo netto
Stato	Hook, con regole d'uso	Rune, usabili ovunque
Dipendenze degli effetti	Array manuale, fonte di bug	Tracciate in automatico
Ottimizzazione manuale	memo, useMemo, useCallback	Non prevista
Moduli	value + onChange a mano	bind:value
Meta-framework	Next.js, Remix, altri	SvelteKit, ufficiale
Librerie di terze parti	Enormi, mature	Poche, a volte fragili
Risposte online e AI	Abbondanti	Scarse
Lavoro in Italia	Maggioranza del mercato	Quasi assente
Curva iniziale	JSX e hook da digerire	Più dolce

Errori comuni nel fare questa scelta

Scegliere sui benchmark. Le classifiche misurano casi sintetici che non somigliano alla tua applicazione: il tuo utente aspetta per un'immagine da 2 MB, non per il DOM virtuale.

Credere che "meno codice" valga più di tutto il resto. Scrivere è la parte breve: manutenere e trovare persone è la parte lunga, e lì l'ecosistema conta più della sintassi.

Valutare React senza il suo meta-framework. React puro non ha routing né dati né rendering sul server: il confronto sensato è Next.js contro SvelteKit.

Decidere il framework prima del progetto. La domanda utile non è "quale è meglio" ma "che cosa devo costruire": il metodo è in quale framework scegliere.

Pensare che sia una scelta definitiva. Entrambi poggiano sulle stesse basi: componenti, stato, eventi, DOM. Chi sa React impara Svelte in una settimana, e viceversa.

Il verdetto per caso d'uso

Quando Svelte è oggettivamente la scelta migliore

• Progetti personali e side project. Nessuno da convincere, nessuno da assumere, meno codice da scrivere la sera. Qui non c'è partita.
• Widget da incastrare in pagine esistenti. Un configuratore dentro un sito WordPress, un calcolatore in una landing page: spedire il runtime di React per un componente è sproporzionato.
• Team piccoli e autonomi. Tre persone che decidono da sé: non hai il problema di trovare il quarto che sappia già lo strumento.
• Quando il peso conta davvero. Siti pubblici con traffico mobile alto, reti lente, pagine dove ogni kilobyte è negoziato.
• Prototipi e MVP. Devi arrivare a qualcosa che funziona in fretta, e forse butterai via tutto.

Quando React resta la scelta giusta

Anche sapendo che su alcuni punti tecnici è inferiore.

• Se stai imparando per lavorare. Non è un dubbio: React. Il mercato non si negozia con gli argomenti tecnici.
• In azienda, su un progetto che vivrà anni. Turnover, assunzioni, subentri: uno stack che tutti conoscono vale più di qualche kilobyte. E se il team già lo conosce, reimparare costa mesi che il beneficio non ripaga.
• Quando il progetto poggia su librerie complesse. Una griglia dati seria o l'SDK maturo di un servizio esterno decidono da soli la scelta.
• Quando serve React Native. Se c'è anche l'app mobile e vuoi condividere competenze, il discorso finisce lì.

Il criterio in una riga: se scegli per il mercato, React. Se scegli per il progetto e il mercato non è un vincolo, Svelte ti farà scrivere meno codice e spedire meno roba.

In sintesi

La differenza di fondo è quando avviene il lavoro: a runtime in React, in fase di compilazione in Svelte. Da lì discende tutto il resto.

Il vantaggio di peso di Svelte è reale ma di partenza, e si assottiglia sulle applicazioni grandi — dove comunque il collo di bottiglia sta quasi sempre altrove.

Svelte fa scrivere meno codice e non ha il problema delle dipendenze degli effetti, e nell'uso quotidiano questo si sente più del bundle.

La ragione vera per cui si sceglie React non è tecnica ed è legittima: ecosistema di un altro ordine di grandezza, risposte online abbondanti e un mercato del lavoro italiano che non lascia spazio a dubbi.

Non è una scelta definitiva. Le basi sono le stesse: quello che cambia da imparare è la sintassi, non il ragionamento.

Per il confronto che include anche Vue e Angular, vedi React, Vue o Angular. Per capire cosa ti serve davvero prima di decidere, come scegliere lo stack per una web app.