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.
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
- 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.
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 <div> nel template, e gestisce solo quella porzione dell'interfaccia. Il resto della pagina rimane Django puro.
Questo approccio è spesso preferibile a scrivere JavaScript vanilla per gli stessi componenti — React porta gestione dello stato, componenti riutilizzabili e un ecosistema di librerie UI, senza richiedere di abbandonare l'architettura Django che già funziona.
Il quadro in sintesi
La scelta non è tra uno strumento migliore e uno peggiore. È tra strumenti con scopi diversi:
- SEO, siti pubblici, contenuti indicizzabili → Next.js
- Applicazioni interne, flussi di processo, dashboard interattive → React puro
- Progetto Django con componenti che richiedono reattività → React integrato, senza SPA