Next.js 16 e React 19: cosa cambia per i nuovi progetti SaaS

Next.js 16 è una release del framework React che rende Turbopack il bundler di default, richiede accesso asincrono alle API legate alla richiesta e si abbina al Compiler stabile di React 19 per rimuovere la memoization a runtime e il boilerplate di gestione form da una codebase SaaS. La release è arrivata il 21 ottobre 2025, prima del Next.js Conf 2025, seguita dalla 16.1 a dicembre.

Per chi sta scegliendo uno stack oggi, la combinazione di Next.js 16 e React 19 cambia la forma di default di un'app in produzione in modi che vale la pena capire prima del primo commit. In questo articolo vediamo cosa è cambiato davvero e cosa significa se stai partendo con un nuovo SaaS nel 2026.

La versione breve

Next.js 16 promuove Turbopack a bundler di default in dev e in produzione, rimuove il supporto a Node.js 18, ed elimina l'accesso sincrono a cookies, headers, params, searchParams e draftMode. Introduce i Cache Components opt-in tramite la direttiva use cache. Oltre a questo, Next.js 16 incorpora le funzionalità di React 19.2: View Transitions, il componente Activity e useEffectEvent.

React 19 porta un compilatore stabile che memorizza automaticamente i componenti in fase di build, Actions con useActionState e useFormStatus per la gestione dei form, e un hook use che legge promise e context in modo compatibile con Suspense. Entrambe le release puntano a un'idea: meno glue a runtime, più primitive esplicite.

Cosa è arrivato con Next.js 16

Turbopack è stabile e di default

Turbopack è in preview da Next.js 13. Nella 16 diventa il bundler di default per i nuovi progetti e raggiunge la stabilità in produzione. Vercel riporta fino a 10x più veloce il Fast Refresh e build di produzione 2 a 5 volte più rapide rispetto a Webpack. La filesystem cache è attiva in development, quindi i tempi di compilazione sopravvivono ai restart. L'adozione era già oltre il 50% delle sessioni di sviluppo e il 20% delle build di produzione sulla 15.3 prima del cambio in 16, ed è per questo che Vercel si è sentita tranquilla a cambiare il default.

Puoi ancora scegliere Webpack nella finestra di transizione, ma un progetto nuovo ha poche ragioni per farlo. Il gap di parità dell'ecosistema si è chiuso sui code path che la maggior parte dei SaaS usa davvero.

Le API di richiesta sono sempre asincrone

Da Next.js 16 l'accesso sincrono è completamente rimosso da cookies(), headers(), draftMode(), params e searchParams. Ogni call site fa l'await dell'API.

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  const cookieStore = await cookies()
  return <Article slug={slug} />
}

La motivazione è la dinamicità esplicita. In Next.js 15 e precedenti, leggere un cookie faceva diventare silenziosamente la pagina dinamica. Ora l'await è visibile e una pagina è dinamica solo quando aspetta qualcosa di dinamico. Il codemod npx @next/codemod@canary upgrade latest gestisce la maggior parte del refactor sul codice esistente.

Cache Components e caching esplicito

I Cache Components reintroducono il caching come primitiva opt-in. Aggiungi use cache in cima a una funzione, componente o pagina, e il compilatore genera la cache key e si aggancia al Partial Pre-Rendering. Tutto ciò che non è marcato use cache gira al momento della richiesta. Il default passa da "cached a meno che non sia dinamico" a "dinamico a meno che non sia cached di proposito", che è il modello mentale che la maggior parte dei team già teneva in testa.

Node.js 18 è fuori

Il runtime minimo è Node.js 20.9.0 LTS. Ha effetti operativi: container image, pipeline CI e piattaforme serverless ferme su Node 18 vanno aggiornate prima dell'upgrade. Per un nuovo SaaS si parte su Node 22 LTS e ci si dimentica.

Cosa porta React 19 allo stesso stack

Il React Compiler è stabile

React 19 rilascia il Compiler (prima noto come React Forget) come strumento opt-in di build-time che memorizza automaticamente componenti e hook. Nella maggior parte dei casi rimuove la necessità di useMemo, useCallback e React.memo. Meta ha riportato fino al 12% di caricamenti iniziali più veloci e oltre 2.5x di interazioni più reattive nel Meta Quest Store dopo l'adozione completa. Sanity Studio ha riportato una riduzione del 20 al 30% del tempo di rendering e della latenza dopo aver precompilato 1.231 dei 1.411 componenti.

La scelta opt-in è voluta. Il compiler assume che il codice rispetti le regole di React; se ci sono escape hatch come mutazioni di props, side effect nel render o ordine incoerente degli hook, il compiler si ferma su quel punto e logga una diagnostica. Per un SaaS greenfield non è un problema. Per una codebase legacy, l'adozione incrementale tramite la direttiva use memo o gli override di Babel permette un rollout modulo per modulo.

Le Actions sostituiscono gran parte del boilerplate sui form

Un'Action è una funzione async che muta stato, tipicamente legata a un form. L'hook useActionState wrappa l'action, espone un flag pending e tiene traccia dei valori di ritorno. useFormStatus legge lo stato pending dai componenti figli. Insieme sostituiscono tre o quattro layer che esistevano prima: loading state, UI ottimistica, gestione errori e, in molti casi, l'intero endpoint REST a cui il form faceva POST.

In un'app Next.js 16 un'Action è tipicamente una Server Action. Il form client fa POST direttamente alla funzione server e il framework gestisce la serializzazione. Questo rimuove il route handler, lo schema di validazione condiviso, il wrapper di fetch e la state machine client-side. Il contratto diventa la firma della funzione.

L'hook use legge promise e context

use() legge una risorsa, una Promise o un Context, e si integra con Suspense. A differenza di ogni altro hook React, può essere chiamato dentro condizionali e loop. In pratica sostituisce la maggior parte dei call site di useContext e elimina il balletto useEffect più useState per i dati async dentro i Client Components.

React 19.2 viaggia dentro Next.js 16

L'App Router della 16 gira su React 19.2 canary. Ti dà il componente Activity (rende UI nascosta preservando lo stato), useEffectEvent (legge l'ultimo valore senza riattivare la subscription) e le View Transitions integrate. Sono feature più piccole, ma ognuna elimina una categoria di workaround.

Cosa significa per un nuovo progetto SaaS

Partire su Next.js 16 e React 19 sposta cinque default allo stesso tempo.

Server Actions invece di handler REST. La maggior parte delle mutazioni interne non ha bisogno di un endpoint HTTP pubblico. Usa le Actions di default, e prendi in mano route.ts solo per webhook di terzi, callback OAuth e API pubbliche.

Opt-in al caching, non affidarsi ad esso. I Cache Components mettono il default su dinamico. Decidi presto quali route e quali data call meritano una direttiva use cache, invece di cachare per sbaglio.

Abbandona la memoization manuale. Abilita il Compiler dal giorno uno. Il team scrive meno useMemo e useCallback, che peraltro sono spesso sbagliati (dipendenze stale, reference dimenticate). Tratta la memoization manuale come un segnale da investigare.

Async ovunque nel request path. Scrivi ogni layout, page e route handler come async. Fai l'await di params, cookies e headers in cima. Il codemod lo fa per te in upgrade, ma su greenfield lo scrivi così dal primo file.

Node 22, TypeScript strict. Parti dal runtime e dalla toolchain che saranno ancora supportati tra 18 mesi. Node 22 LTS e TypeScript strict mode attivi dal giorno uno.

Quando aggiornare un progetto esistente

Per i team in Next.js 15, il codemod delle API async gestisce il refactor in pochi minuti. Il lavoro vero sono tre verifiche: controllare che Turbopack compili l'app senza warning (attenzione a loader Webpack custom e plugin legacy), portare Node.js a 20.9 o 22 su CI e produzione, e fare un audit del codice che assumeva il caching di default. Il React Compiler può aspettare, visto che è opt-in; un rollout graduale con la direttiva use memo è meno rischioso di un flip globale.

Per i team in Next.js 14 o precedenti l'upgrade è in due step: prima 15, poi 16. I cambiamenti dell'App Router e la rimozione di cookies() sincrono sono più facili da assorbire in sequenza che insieme. Un SaaS greenfield non affronta nessuna delle due decisioni, ed è per questo che i progetti nuovi del 2026 hanno il percorso più breve verso uno stack production-grade degli ultimi anni.