Applicazioni a singola pagina (SPA)
Sulla base dell’ottimo articolo di Addy Osmani “Building Single Page Applications With jQuery’s Best Friends” (Costruire Applicazioni a Pagina Singola con i migliori amici di jQuery) cogliamo l’occasione per parlare appunto delle Applicazioni a Singola Pagina o più semplicemente SPA.
Cos’è un’applicazione a singola pagina (SPA)?
Le SPA sono applicazioni web o siti web che vengono visualizzati sempre nella stessa pagina senza necessità di dover richiedere un ulteriore caricamento di dati durante la navigazione. Tutto il codice necessario al caricamento iniziale in queste applicazioni è estratto da dati locali o da dati recuperati a richiesta da un server web, come ad esempio i dati aggiuntivi che possono essere richiesti dalla vostra applicazione atraverso le azioni degli utenti che sfruttano la vostra applicazione o navigano sul vostro sito.
L’idea di base di una SPA è che, indipendentemente da come gli utenti interagiscono con la vostra applicazione/sito web, la pagina non venga mai ricaricata o sia controllata/gestita da un’altra pagina al di fuori di quella attuale.
Perché le SPA doverbbero essere migliori delle applicazioni multi-pagina?
Le SPA in genere contrastano con le classiche applicazioni web multi-pagina in cui i cambiamenti di pagina sono regolari ed al browser viene richiesto di recuperare nuovi contenuti dal server e quindi ricaricare la pagina per soddisfare le richieste degli utenti.
Il problema dato dall’approccio classico multi-pagina è che la navigazione richiesta dall’utente non è fluida in quanto c’è un evidente passaggio da una pagina a quella successiva che richiede l’attesa dovuta al fatto che la nuova pagina e tutti i suoi contenuti devono essere caricati. Questo spesso significa richiedere lo stesso contenuto più e più volte (pensiamo ad esempio agli header, ai footer o alle barre laterali di navigazione). Con una SPA invece, i cambiamenti di ‘stato’ dell’applicazione sono molto più fluidi e quasi impercettibili, in quanto gestiti mediante approcci XHR, e ciò comporta di conseguenza una maggiore ‘attenzione’ dell’utente che sta navigando il sito od usufruendo dell’applicazione.
In una applicazione web server-side (senza alcun javaScript client-side) si può considerare l’idea di sequenza di stato equivalente alla nozione di pagina. Un cambiamento/modifica parziale in una SPA (come ad esempio la visualizzazione di un modulo di contatto) implica un cambiamento di stato nello stesso modo in cui la navigazione in una applicazione server-side implica un cambio di pagina.
Le SPA ed i Motori di Ricerca
Tutto ciò però comporta il fatto che se utilizzassimo una SPA questa sarebbe invisibile ai motori di ricerca (compreso Google) ed a tutti quegli utenti che avessero disabilitato i motori javascript.
Come possiamo risolvere questo problema? Semplicemente attraverso un ovvio ‘degrado grafico’ ed un’altrettanto ovvio utilizzo di chiamate con query a parametri standard: se in javascript avessimo una chiamata del tipo #/libri/12345, la chiamata standard dovrebbe essere del tipo /?categoria=libri&id=12345.
Un ‘degrado’ di questo tipo consentirebbe agli utenti di continuare la navigazione ed ai Bots di eseguire comunque il loro lavoro. Potremmo semplicemente ‘collegare’ questi due schemi con una logica di redirect lato server nel caso avessimo bisogno di avere un maggiore livello di controllo.
Nell’articolo di Addy Osmani vengono utilizzati:
- Backbone.js
- Underscore.js
- jQuery Templating
- LAB.js Script loader
- Dustin Diaz’s CacheProvider
- JSDoc Toolkit
per creare una una galleria di immagini a tre livelli.
Consiglio a tutti la lettura di questo articolo che, come sempre, è esaustivo e ricco di spunti.
Sito autore: http://addyosmani.com/