← Tutti gli articoli

Next.js 13.4 e l'App Router stabile: cosa cambia davvero

12 July 20232 min di lettura

Vercel ha dichiarato stabile l'App Router con la 13.4. Tra Server Components, layout annidati e nuove convenzioni di routing, capiamo cosa adottare subito e cosa lasciar maturare.

Il 4 maggio 2023 Vercel ha annunciato la versione 13.4 di Next.js, dichiarando per la prima volta stabile l'App Router. Per chi sviluppa applicazioni web in azienda è una notizia di peso: il modello su cui costruire i prossimi progetti è ora ufficiale, anche se la migrazione dalle vecchie applicazioni in pages/ resta una scelta da pesare con cura.

Cosa rende l'App Router diverso

La novità centrale non è la nuova cartella app/, ma l'adozione dei React Server Components come default. In pratica ogni componente è eseguito sul server salvo dichiarazione esplicita con "use client". Questo cambia il modo in cui pensiamo lo state, la cache e il fetching dei dati: niente più getServerSideProps, niente più useEffect per caricare la prima pagina.

Layout annidati e UI persistente

Il file layout.tsx in ogni directory diventa un layout permanente che non viene smontato durante la navigazione. Per chi ha una sidebar, una topbar o uno stato di playback, è la differenza tra un'app web vera e un sito che ricarica tutto a ogni click.

Streaming e Suspense

L'App Router abbraccia lo streaming HTTP: la pagina arriva al browser progressivamente, con i blocchi pronti subito e i blocchi lenti gestiti da <Suspense>. Per chi misura i Core Web Vitals è un cambio di paradigma: il TTFB scende, il LCP si stabilizza, e l'esperienza percepita migliora anche su connessioni lente.

Cosa abbiamo deciso in SEM Devs

Per i progetti nuovi adottiamo l'App Router come default da subito. Per quelli esistenti facciamo l'opposto: nessuna migrazione forzata. Convivere con pages/ e app/ nello stesso progetto è supportato, e ha senso introdurre l'App Router solo quando una nuova feature o un refactoring lo giustificano.

I tre punti su cui prestare attenzione

  • Caching aggressivo: il fetch è cachato di default. Per dati dinamici servono direttive esplicite (cache: "no-store" o revalidate).
  • Server Actions ancora alpha: utili da provare, ma in produzione restiamo su API routes finché non saranno stabili.
  • Librerie client-only: alcune dipendenze (date pickers, charting) richiedono boundary "use client" espliciti, e questo pesa sul bundle.

Vale la pena passarci?

Sì, ma con un piano. Per le PMI con cui lavoriamo l'App Router significa pagine più veloci, meno JavaScript spedito al browser, e un modello mentale più vicino al backend. Significa anche curve di apprendimento, soprattutto per team abituati a Redux e a fetching client-side. La nostra raccomandazione: partire dai progetti nuovi, lasciare maturare quelli esistenti, e prepararsi a Next.js 14 dove le promesse di oggi diventeranno fondamenta.