React vs Next.js: quale scegliere per il tuo progetto web

Non è una gara

React e Next.js non sono in competizione. Next.js è costruito sopra React — usa React per il rendering dei componenti e ci aggiunge routing, gestione del server, ottimizzazione delle immagini e molto altro.

Se non hai ancora chiaro cosa sia Next.js e come funziona, ho scritto un articolo dedicato: Next.js: cos'è, come funziona e quando usarlo. Torna qui quando vuoi capire quale dei due scegliere per il tuo progetto.

Dire "uso Next.js" non significa scegliere qualcosa di diverso da React. Significa scegliere React con un layer aggiuntivo sopra. La domanda giusta non è quale dei due sia migliore, ma quale dei due sia necessario per il tuo progetto.

Usare Next.js dove non serve è overkill. Usare React puro dove serviva Next.js è un problema da risolvere dopo, quando i requisiti crescono.

Cosa fa React da solo

React è una libreria per costruire interfacce utente. Gestisce il rendering dei componenti e lo stato dell'interfaccia — niente routing, niente server, niente ottimizzazioni SEO built-in.

Il risultato è una Single Page Application (SPA): il browser scarica JavaScript, lo esegue, e React costruisce l'interfaccia lato client. Il server non conosce l'interfaccia — serve solo file statici.

Questo modello ha vantaggi reali:

• Semplicità architetturale: nessun server da gestire, deployment su qualsiasi CDN o hosting statico
• Reattività nativa: l'interfaccia risponde agli input senza round-trip al server
• Isolamento: l'applicazione è completamente separata dal backend
• Costo ridotto: hosting di file statici è economico e scalabile quasi gratuitamente

I limiti sono altrettanto reali:

• SEO debole: i motori di ricerca ricevono una pagina vuota e aspettano che JavaScript carichi il contenuto
• Primo caricamento lento: l'utente vede qualcosa solo dopo che il bundle JavaScript è scaricato ed eseguito
• Nessuna logica server: per dati sensibili o operazioni backend serve comunque un'API separata

Cosa aggiunge Next.js

Next.js risolve esattamente i limiti di React puro aggiungendo:

• Server Side Rendering (SSR): le pagine vengono generate sul server a ogni richiesta. Il browser riceve HTML già pronto, il contenuto è immediatamente visibile e indicizzabile.
• Static Site Generation (SSG): le pagine vengono generate a build time. Velocissimo, ideale per contenuti che cambiano raramente.
• App Router e React Server Components: componenti che girano sul server, riducono il JavaScript inviato al client e semplificano il fetching dei dati.
• Ottimizzazioni automatiche: immagini, font, script — gestiti senza configurazione manuale.
• API Routes: endpoint backend integrati nel progetto frontend per casi semplici.

Il costo di tutto questo è una maggiore complessità: un server da gestire, una curva di apprendimento più ripida, un deploy che non è più un semplice upload di file statici.

Quando React puro è la scelta giusta

React senza Next.js non è una scelta di ripiego — è la scelta corretta in scenari precisi.

Applicazioni interne e gestionali: un CRM su misura, un pannello di monitoraggio, un tool per i dipendenti, un configuratore di prodotti. Questi strumenti non devono essere indicizzati da Google, sono accessibili solo dopo login, e spesso hanno flussi complessi e interattivi. Il SEO non è un requisito. Aggiungere Next.js non porta nessun vantaggio e introduce complessità inutile.

Flussi di processo e wizard multi-step: form complessi, configuratori, processi guidati con molti stati intermedi. React gestisce questo tipo di interfaccia in modo naturale — lo stato vive nel client, i passaggi sono fluidi, non c'è motivo di coinvolgere un server per ogni interazione.

Dashboard con dati in tempo reale: se i dati cambiano continuamente — grafici live, notifiche, feed — il vantaggio del rendering server-side si azzera. Il dato che il server ha renderizzato è già vecchio quando arriva al browser. Meglio una SPA che si aggiorna direttamente.

Quando il team non conosce Next.js: l'App Router di Next.js introduce concetti non banali — React Server Components, streaming, caching a più livelli. In un team che conosce già React ma non Next.js, il costo di apprendimento è reale e va considerato nella stima del progetto.

Quando Next.js è la scelta giusta

Next.js diventa necessario quando il progetto è pubblico e deve essere trovato su Google.

Siti aziendali, landing page, blog: il contenuto deve essere indicizzato, il tempo al primo contenuto visibile conta, e spesso il progetto deve essere consegnato a un cliente che non gestisce infrastruttura. Next.js risolve tutto questo out of the box.

E-commerce e portali: pagine prodotto, categorie, contenuti editoriali — tutto ciò che deve posizionarsi nei motori di ricerca. SSR o SSG sono requisiti, non opzioni.

Progetti che crescono nel tempo: avere routing, API, ottimizzazioni e deployment integrati riduce le decisioni architetturali future. Se i requisiti cambiano — e cambiano sempre — avere Next.js già in pila è un vantaggio.

React dentro Django: un caso spesso sottovalutato

C'è un terzo scenario che vale la pena nominare esplicitamente: integrare React in un progetto Django esistente, senza costruire una SPA completa né adottare Next.js.

Django è un framework web maturo con templating, routing e ORM già inclusi. In molti progetti, il 90% dell'interfaccia è HTML tradizionale servito da Django — form, tabelle, pagine statiche. Ma ci sono componenti specifici che beneficerebbero di reattività: un filtro dinamico, una tabella con ordinamento e paginazione lato client, un form multi-step, un'interfaccia drag-and-drop.

In questi casi, costruire un'intera SPA React o adottare Next.js è eccessivo. La soluzione più pulita è includere React solo dove serve, montandolo su uno o più elementi specifici della pagina Django. React viene caricato come bundle standalone, si aggancia a un