Guide

«SPA vs PWA» è una delle confusioni più comuni nello sviluppo front-end, e il motivo è semplice: i due termini non sono affatto opposti. Una single-page application (SPA) descrive come un’applicazione è costruita e naviga, mentre una progressive web app (PWA) descrive cosa un’applicazione può fare per l’utente. Metterle a confronto diretto è un po’ come chiedere «auto manuale o elettrica»: stai paragonando due assi diversi, e un’app può tranquillamente essere entrambe, una sola o nessuna delle due.

Cos'è una SPA

Una single-page application carica un unico documento HTML e poi riscrive la pagina nel browser mentre navighi, invece di recuperare una pagina nuova dal server a ogni clic. Dopo il primo caricamento, il JavaScript sostituisce le parti rilevanti dell’interfaccia e recupera solo i dati che servono, di solito come JSON da un’API. Il risultato si avvicina a un’applicazione desktop o mobile, con transizioni istantanee e senza ricaricamenti completi della pagina. React, Vue, Svelte e Angular esistono in gran parte per rendere praticabile questo modello.

Cos'è una PWA

Una progressive web app è un’idea del tutto diversa: è un sito web che usa gli standard web moderni per comportarsi più come un’app installata. I tre pilastri sono un manifest dell’applicazione web (per poterla aggiungere alla schermata home con un’icona e un nome), un service worker (uno script in grado di mettere in cache le risorse e servirle offline) e HTTPS (necessario per queste capacità). Una PWA può inviare notifiche push, funzionare senza connessione e avviarsi in una propria finestra, tutto da un URL normale, senza alcuno store di applicazioni.

• SPA = architettura (navigazione lato client, senza ricaricamenti)
• PWA = capacità (installabile, offline, push)
• Una PWA è spesso una SPA, ma nessuna richiede l’altra
• L’SSR è un asse a parte (rendering, non tipo di applicazione)
• Scegli in base a ciò che serve al prodotto, poi aggiungi le funzionalità

Perché non sono opposti

Questo è il cuore della confusione che vale la pena chiarire: le due non si escludono a vicenda. Una PWA è molto spesso costruita come una SPA, ma non è obbligatorio: puoi aggiungere un manifest e un service worker a un sito multipagina tradizionale e renderlo una PWA. Allo stesso modo, molte SPA non sono affatto PWA, perché non aggiungono mai il supporto offline o l’installabilità. La SPA riguarda l’architettura di navigazione; la PWA riguarda la distribuzione e le capacità aggiunte sopra.

I compromessi di una SPA

Considerato di per sé, il modello SPA ti garantisce un’interattività fluida a un certo prezzo. Una volta caricato il bundle, le interazioni sono rapide perché l’applicazione richiede dati anziché interi documenti. Ma il primo caricamento è più pesante — il browser deve scaricare ed eseguire JavaScript prima di mostrare contenuti significativi — e i motori di ricerca possono vedere un guscio vuoto se non esegui il rendering sul server. Le SPA brillano per dashboard, editor e prodotti di tipo applicativo, meno per i semplici siti di contenuti.

I compromessi di una PWA

Le capacità di una PWA risolvono un problema diverso: il riavvicinamento degli utenti e la resilienza. Il supporto offline significa che l’app continua a funzionare su una connessione ballerina in treno; l’installabilità mette un’icona nella schermata home e rimuove la cornice del browser; le notifiche push riportano indietro gli utenti. Anche i compromessi sono reali: i service worker aggiungono una complessità di caching che può servire contenuti obsoleti se gestita con poca attenzione, e il supporto di Apple su iOS, pur molto migliorato, resta in alcuni punti indietro rispetto ad Android.

Dove si colloca l'SSR

Un terzo termine di solito irrompe in questo confronto: l’SSR, ovvero il rendering lato server. Vale la pena separarlo perché è ancora un altro asse: una strategia di rendering, non un tipo di applicazione. I meta-framework come Nuxt e Next.js eseguono il rendering della prima pagina sul server, così utenti e motori di ricerca ottengono subito contenuti reali, per poi idratarla in una SPA nel browser. Puoi combinare l’SSR con una SPA, e anche una PWA può usare l’SSR; nessuna di queste etichette esclude le altre.

Come scegliere

Quindi, come scegliere concretamente? Parti da ciò di cui ha bisogno il prodotto, non dall’acronimo. Se è molto interattivo e si comporta come un software, l’architettura SPA è adatta. Se gli utenti trarrebbero vantaggio dall’accesso offline, dall’installabilità o dalle notifiche push, aggiungi le capacità PWA sopra: è incrementale per progettazione, ed è proprio ciò che significa «progressive». Se il sito è soprattutto contenuto e il SEO conta più di tutto, appoggiati al rendering lato server o persino a un approccio multipagina tradizionale, e aggiungi funzionalità PWA solo dove ripagano davvero.

In sintesi

La conclusione onesta è che «SPA vs PWA» è l’inquadramento sbagliato. Sono livelli complementari: uno decide come naviga la tua app, l’altro decide cosa può fare una volta che è lì. Le app web moderne più solide spesso combinano tutte e tre le idee — una SPA per l’interattività, il rendering lato server per un primo disegno rapido e per il SEO, e le funzionalità PWA per l’offline e l’installabilità — scelte in modo deliberato anziché trattate come schieramenti rivali.