Miglioramento progressivo rispetto alle app a singola pagina

Mi sembra che le app a pagina singola disegnino una linea nella sabbia del miglioramento progressivo. Dove prima potremmo cercare di aggirare il fatto che implementazioni e funzionalità variano tra i browser che risalgono da decenni, le SPA presuppongono che ci sia una certa linea di base che possiamo ragionevolmente concordare con la maggior parte dei visitatori di un dato sito. Non penso che i due siano in disaccordo. Puoi comunque continuare a migliorare progressivamente dopo l'avvio della SPA, ad esempio iniziare con un tag <video> , quindi sovrapporre il tuo player ricco di funzionalità.

Poi ci sono visitatori con script disabilitati, ma sanno a cosa stanno andando incontro. Non vedo perché gli sviluppatori dovrebbero piegarsi all'indietro per quei visitatori, a parte una nota "Hai bisogno di script per questo sito". Se lo permettiamo, perché non soddisfare anche i visitatori con i CSS disabilitati? Che ne dici di immagini disabilitate? Queste sono tecnologie web fondamentali. Non dovrebbero aspettarsi di avere un'esperienza web completa quando scelgono e scelgono pezzi.

Per assicurarmi che non vada via senza un'analogia con l'auto, non dovrei aspettarmi che la mia macchina funzioni se decido che non mi piacciono certe caratteristiche. Potrei dire agli ingegneri civili: "Ho disabilitato i miei fari, quindi per favore assicurati di installare le luci delle strade ogni 25 metri ovunque io visiti". Senza i fari, la mia macchina lavorerebbe molto tempo, ma in alcuni posti non potrò visitare.

SPA è molto utile se si sta creando un'applicazione che non si adatta al classico modello di pagine di richiesta / risposta. C'è una tendenza recente in cui i normali siti web sono scritti come una SPA anche quando si adattano perfettamente al ciclo di richiesta / risposta del web, IMHO quello che stanno facendo sono sciocchi tentativi. Ciò che piace a questi siti Web è il reimplementing di un browser Web con molti più bug e meno funzionalità.

L'idea di miglioramento progressivo e SPA non si escludono a vicenda per questi insensati siti web di app di una sola pagina. È sufficiente che il javascript esegua la negoziazione del contenuto (ad esempio Accept header) in modo che riceva la risorsa JSON che il Javascript sullo SPA può eseguire il rendering anziché una pagina HTML pre-renderizzata. I problemi con questo tipo di SPA sito web sono ovvi, devi avere una duplice implementazione del rendering del sito web sia sul server che sul client.

Per le vere applicazioni web, ad esempio una che deve essere una SPA in quanto non si adattano al modello di richiesta / risposta standard; il miglioramento progressivo è molto più difficile per le applicazioni reali perché in realtà usano solo un browser come piattaforma tecnologica per scrivere un'applicazione in modo portabile. Il linguaggio di scripting è una parte essenziale di una vera applicazione web, non solo una che può essere opzionalmente imbullonata per miglioramenti. Tuttavia, alcune tecniche di miglioramento progressivo possono ancora funzionare (ad esempio sostituendo flash video / audio con <video> / <audio> tag), ma le applicazioni Web reali richiedono javascript come base di riferimento.

Credo che le applicazioni web a pagina singola e il miglioramento progressivo siano quasi antagonisti. Se l'html è calcolato sul client dai dati recuperati da una API json, difficilmente può degradare con grazia. Può tuttavia offrire un'interfaccia utente più ricca e piacevole.

Puoi configurare un bot che eseguirà la ricerca per indicizzazione dell'applicazione e salverà una versione statica. Questa tecnica può essere utilizzata per fornire HTML ai browser senza javascript (utilizzato da persone non vedenti o bot dei motori di ricerca). Questo è un investimento, quindi dipende davvero dalle tue esigenze.

Stai realizzando un'app Web di gestione delle risorse umane per una compagnia specifica? Non è necessario un degrado graduale e una SPA potrebbe essere più semplice da costruire. L'azienda può far valere l'uso di un browser specifico, quindi è possibile che ci siano meno test da fare.

Stai creando un sito Web pubblico per un'associazione con i requisiti di accessibilità e le esigenze di visibilità dei motori di ricerca? Quindi considera la possibilità di creare l'HTML sul tuo server. Oppure creare una SPA con una versione statica, a seconda del budget.

Penso che dipenda da quanto lontano vuoi andare con Progressive Enhancement: è un paradigma di design piuttosto che una serie di regole rigide.

Se stai usando un framework SPA, penso che consentire Javascript sia un dato di fatto. Tuttavia il Javascript che scrivi per migliorare la tua pagina deve essere abbastanza intelligente da gestire qualsiasi HTML possa creare il framework.

Puoi anche trarre vantaggio da altre tecniche PE come sfruttare le ultime funzionalità CSS per una recente versione del browser o la degradazione da HTML5 a HTML4.

Il miglioramento progressivo e un'applicazione per pagina singola possono coesistere. I due argomenti più convincenti che ho sentito per la creazione di app in questo modo sono:

• Tolleranza agli errori nelle situazioni in cui il download del file HTML in pieno ma gli script di riferimento non riescono a scaricarsi completamente grazie alla connettività di rete che entra ed esce (possibile sulle reti mobili)
• Potenziale per miglioramento delle prestazioni percepite sul caricamento iniziale della pagina (riducendo i tempi di Avvio rendering)

Il rendering lato server (questo è per gli utenti, non solo per ragioni SEO) e il taglio-the-mostard sono due tecniche che possono aiutare a creare applicazioni a singola pagina progressivamente migliorate con i moderni framework JS lato client.

Alcuni framework JS lato client sono più facili da utilizzare con il rendering lato server rispetto ad altri ( attenzione alcune soluzioni di rendering lato server e combinazioni di framework non producono SPA funzionanti in quanto la pagina di rendering server è destinata esclusivamente a consumo del motore di ricerca, non utenti finali ).

Al momento della scrittura, React.js ed Ember (con l'imminente FastBoot) sono le due che sono a conoscenza di ciò che hanno o stanno cercando di rendere il rendering lato server un cittadino di prima classe; la pagina di rendering lato server è ancora una SPA funzionante quando viene analizzata sul browser client.

Sono del parere che il carico ridotto della pagina è probabilmente abbastanza buono per i server e la rete. Mi piacerebbe vedere più SPA usate correttamente.

Non sono d'accordo che ciò richieda due cose:

1) impostazione di tutti i collegamenti come collegamenti di richiesta / risposta standard al caricamento iniziale, lasciare che il framework / libreria SPA li sostituisca con una versione aggiornata (interattiva) una volta che il browser viene caricato e il motore JS identifica che il supporto SPA è a disposizione. Questo è davvero un miglioramento progressivo; il JS viene caricato sul sito Web html esistente, e questo è migliore per motori di ricerca, tecnologie assistive e browser meno recenti.

e

2) Il server deve essere reattivo ai percorsi come / foo / bar / json e foo / bar servendo il formato corretto; realisticamente se stai avvolgendo tutto in layout e partial per ottenere la prima pagina, dovresti essere in grado di ottenere tutto tramite layout e partial per la seconda e le successive pagine.

C'è un bel po 'di lavoro qui; bisogna ammetterlo, ma se hai il controllo sull'intero stack, bilancia le due tecnologie.