Miglioramento progressivo rispetto alle app a pagina singola

33

Sono appena tornato da una conferenza a Boston chiamata An Event Apart .

Un tema molto popolare tra gli oratori era l'idea del miglioramento progressivo : il contenuto di un sito dovrebbe essere inserito in HTML e JavaScript dovrebbe essere utilizzato solo per migliorare il comportamento.

Le argomentazioni fornite dagli oratori per il miglioramento progressivo sono state molto convincenti. Non solo è un modello solido per il supporto di browser meno recenti e dispositivi su una rete con larghezza di banda ridotta, ma l'HTML fallisce molto più elegantemente di JavaScript (ovvero il markup non supportato viene semplicemente ignorato, mentre se un browser genera un'eccezione durante l'esecuzione del tuo sceneggiatura: sei colto).

Jeremy Keith ha tenuto un discorso particolarmente approfondito al riguardo.

Ma che dire delle app Web a pagina singola come Backbone e Angular? L'intero design dietro questi framework sembra spingere lo sviluppatore verso lo spostamento di contenuti dall'HTML e verso qualcosa come un'API JSON.

Non riesco a gelificare questi due modelli di progettazione: miglioramento progressivo rispetto alle app Web a pagina singola. Ci sono casi in cui uno è migliore dell'altro? O non sono nemmeno tecnologie antagoniste, e mi manca qualcosa qui con il mio modello mentale?

— SeanPlusPlus
fonte

Hanno due diversi casi d'uso. Sì, c'è una sovrapposizione quando il server sta eseguendo il sollevamento pesante.

— BobDalgleish,

5

Penso che sia corretto affermare che i requisiti del browser per le applicazioni a pagina singola sono più rigorosi di quelli per le applicazioni web "ordinarie", in base alla progettazione.

— Robert Harvey,

3

dovresti chiedere a Jeremy Keith di darti un esempio nel mondo reale in cui il miglioramento progressivo in realtà merita la seccatura di soddisfare l'1-10% delle persone di Internet in totale e chiedere i dati dell'altro 90% degli utenti, se davvero si preoccupano del miglioramento progressivo o se sono felici se possono visitare il sito Web con IE 5.0 o senza javascript

— kirie

1

Se il tipo di persone che disabilitano JS / images / etc non sono nel tuo target demografico principale, allora non ci sono motivi commerciali validi per perseguire il Progressive Enhancement.

— Graham,

1

Il supporto per "dispositivi su una rete con bassa larghezza di banda" è in realtà un argomento per SPA, non contro di essa! In SPA fai solo una grande richiesta, dove senza JS ce l'hai ogni volta!

— Dmitri Zaitsev,

21

Mi sembra che le app a pagina singola tracciano una linea nella sabbia del miglioramento progressivo. Laddove prima potremmo provare a aggirare il fatto che le implementazioni e le funzionalità variano da browser a decenni, le SPA ipotizzano che ci sia una certa base che possiamo ragionevolmente concordare sul fatto che la maggior parte dei visitatori di un determinato sito si incontreranno. Non penso che i due siano in contrasto. Puoi continuare a migliorare progressivamente dopo l'avvio della SPA, come iniziare con un <video>tag, quindi sovrapporre il tuo giocatore ricco di funzionalità.

Poi ci sono visitatori con lo scripting disabilitato, ma sanno cosa stanno facendo. 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 CSS disabilitato? Che ne dici di immagini disabilitate? Queste sono le principali tecnologie web. Non dovrebbero aspettarsi di avere un'esperienza web completamente funzionale quando scelgono e scelgono pezzi.

Per essere sicuro di non scappare senza un'analogia con un'auto, non dovrei aspettarmi che la mia auto funzioni se decido che alcune funzioni non mi piacciono. Potrei dire agli ingegneri civili: "Ho disabilitato i miei fari, quindi assicurati di installare i lampioni ogni 125 piedi ovunque io possa visitare". Senza fari, la mia macchina funzionerebbe molto, ma alcuni posti che non potrò visitare.

— Collin Allen
fonte

3

I don't see why developers should bend over backwards for those visitors. Se il contratto specifica che è necessario fornire una versione accessibile del sito Web, potrebbe essere più difficile utilizzare una SPA. E che dire del SEO?

— Simon Bergot,

7

@Simon: puoi rendere accessibile anche una SPA (vedi ad esempio stackoverflow.com/questions/15318661/… ). Allo stesso modo per il SEO (se il SEO conta, che dipenderà dall'app).

— sleske,

2

Alcune delle tue analogie sono un po 'un uomo di paglia. La disabilitazione di Javascript ha uno scopo di sicurezza; sarebbe difficile sostenere che l'aggiunta di fari a una cura lo rende meno sicuro.

— Robert Harvey,

1

È vero, la disabilitazione degli script ha vantaggi in termini di sicurezza. Ma per la maggior parte dei visitatori, la sicurezza aggiuntiva offerta dalla scelta non vale la pena. Senza script, Facebook si rifiuta di funzionare, interruzioni di LinkedIn, interruzioni di Pinterest, Instagram carica una pagina vuota, ecc. Se i principali giocatori lo richiedono, anche la tua SPA può farlo.

— Collin Allen,

Conoscendo solo FB e LinkedIn, non vi è alcuna buona ragione per cui quei siti si rompano senza JS se non per placare gli sviluppatori che non vogliono impegnarsi a creare un sito Web accettabilmente funzionante (o costringere gli utenti ad accettare pratiche di navigazione meno sicure che possono trarre vantaggio dai loro profitti). Se fossero applicazioni web complete come Plunker, potresti avere un punto, ma la maggior parte delle "app web" sono solo "app", nel senso che sono costruite su un qualche tipo di framework. In termini di utilizzo, sono solo siti web con più campane e fischietti rispetto al passato.

— Dissident Rage,

6

SPA è particolarmente utile se si sta creando un'applicazione che non si adatta al modello classico di pagine di richiesta / risposta. Esiste una tendenza recente in cui i normali siti Web vengono scritti come SPA anche quando si adattano perfettamente al ciclo di richiesta / risposta del Web, IMHO ciò che stanno facendo sono attività folli. Ciò che piace a questi siti Web è reimplementare male un browser Web con molti più bug e meno funzionalità.

L'idea del miglioramento progressivo e della SPA non si escludono a vicenda per questi stupidi siti Web di applicazioni a pagina singola. Hai semplicemente bisogno del javascript per fare un po 'di negoziazione dei contenuti (ad es. Accetta l'intestazione) in modo che ricevano risorse JSON che il Javascript sulla SPA può rendere se stessi invece di una pagina HTML pre-renderizzata. I problemi con questo tipo di SPA del sito Web sono ovvi, devi avere un'implementazione duplicata del rendering del sito Web sia sul server che sul client.

Per vere applicazioni Web, ovvero una che deve essere veramente una SPA poiché non si adatta al modello standard di richiesta / risposta; il miglioramento progressivo è molto più difficile per le vere applicazioni perché usano davvero un browser come piattaforma tecnologica per scrivere portabilmente un'applicazione. Il linguaggio di scripting è una parte essenziale di una vera applicazione web, non solo quella che può essere opzionalmente fissata per miglioramenti. Alcune tecniche di miglioramento progressivo possono comunque funzionare (ad esempio la sostituzione di video / audio flash con <video>/ <audio>tag), ma le vere applicazioni Web richiedono javascript come base.

— Lie Ryan
fonte

+1, ma non è sempre facile decidere se qualcosa "veramente" richiede una SPA. Ad esempio, applicazioni aziendali che sono per lo più immissione di dati, con una vasta gamma di complessità nei moduli. Se la maggior parte dei moduli è semplice, una SPA non è "veramente" richiesta, quindi c'è ancora tensione tra le soluzioni SPA e non SPA.

— sinelaw,

@sinelaw: la maggior parte delle applicazioni aziendali in genere non dovrebbe essere una SPA. Ci sono alcune eccezioni, ad esempio foglio di calcolo, elaborazione testi, ma quelle sono quelle strane. Indicatori di cui hai bisogno di SPA: se devi trasferire i dati dal server al client, non solo per una o due notifiche, ma come elemento cruciale dell'applicazione, ad es. Gioco, tracciamento delle scorte, app di chat; se la tua applicazione non ha un concetto ragionevole di "Pagina" o il concetto di "Pagina" è stato completamente contorto nell'app, ad esempio le applicazioni di Office. Le applicazioni aziendali che funzionano principalmente su moduli rimangono meglio come non SPA.

— Lie Ryan,

Essere d'accordo. Un altro indicatore per una SPA: se lo sviluppo di una SPA è più economico rispetto allo sviluppo di un sito Web "classico". Le app aziendali rivolte a un pubblico specifico a volte possono imporre requisiti come "utilizzare un browser moderno", in modo che il miglioramento progressivo porti pochi benefici.

— sinelaw

@sinelaw: la costruzione di una SPA non è quasi mai più economica dello sviluppo di siti multipagina; soprattutto se comunque non stai rifornendo i browser più vecchi.

— Lie Ryan

Se il tuo team è composto da esperti di SPA con poca esperienza in progetti incentrati sul server, sarà più economico.

— sinelaw,

2

Credo che le app Web a pagina singola e il miglioramento progressivo siano quasi antagonisti. Se l'html viene calcolato sul client dai dati recuperati da un API JSON, difficilmente può degradarsi con garbo. Può tuttavia offrire un'interfaccia utente più ricca e piacevole.

È possibile impostare un bot che eseguirà la scansione 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 robot dei motori di ricerca). Questo è un investimento, quindi dipende davvero dalle tue esigenze.

Stai creando un'app Web di gestione delle risorse umane per una compagnia specifica? Non è necessario un grazioso degrado e una SPA può essere più semplice da costruire. La società potrebbe imporre l'utilizzo di un browser specifico, quindi potresti avere meno test da fare.

Stai creando un sito Web pubblico per un'associazione con requisiti di accessibilità e esigenze di visibilità dei motori di ricerca? Quindi prendere in considerazione la creazione di HTML sul server. O fare una SPA con una versione statica, a seconda del budget.

— Simon Bergot
fonte

1

Penso che dipenda da quanto lontano vuoi andare con Progressive Enhancement: è un paradigma di progettazione piuttosto che un insieme 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 qualunque HTML il framework possa creare.

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

— philicomus
fonte

1

Parte del miglioramento progressivo è che i contenuti di base dovrebbero essere disponibili senza javascript. Non sono sicuro di come scrivere una SPA senza javascript.

— Alan Shutko,

@AlanShutko Forse con iframe. Più pagine, ma tecnicamente l'URL non cambia ...;)

— Izkata

1

Sì, immagino che stavo pensando di più in termini di HTML 5 vs HTML 4 e cose come CSS specifico del browser (ad esempio potresti voler utilizzare una funzionalità implementata molto di recente disponibile solo nell'ultima versione di Chrome ma che degrada a un controllo primitivo nei browser meno recenti). Fare senza javascript sarebbe complicato in una SPA, ma questa è solo una parte del concetto di miglioramento progressivo.

— philicomus,

Il miglioramento progressivo potrebbe essere semplice come usare css3 quando è disponibile per arrotondare gli angoli. L'idea di base non ha nulla a che fare con JavaScript.

— Daniel Little,

1

Il miglioramento progressivo e un'app a pagina singola possono coesistere. I due argomenti più avvincenti che ho sentito per costruire app in questo modo sono:

Tolleranza agli errori in situazioni in cui il download del file HTML completo ma gli script di riferimento non riescono a scaricare completamente grazie alla connettività di rete che entra e esce (possibile su reti mobili)
Potenziale per migliorare le prestazioni percepite al caricamento della pagina iniziale (riducendo i tempi di avvio del rendering)

Il rendering sul lato server (questo è per gli utenti, non solo motivi SEO) e il taglio della senape sono due tecniche che possono aiutare a costruire app a pagina singola progressivamente migliorate con moderni framework JS sul lato client.

Alcuni framework JS sul lato client sono più facili da utilizzare con il rendering sul lato server rispetto ad altri ( attenzione ad alcune soluzioni di rendering lato server e combinazioni di framework non producono SPA funzionanti poiché la pagina renderizzata dal server è destinata solo al consumo dei motori di ricerca, non alla fine -user ).

Al momento in cui scrivo, React.js ed Ember (con l'imminente FastBoot) sono i due di cui sono a conoscenza e che stanno cercando di rendere il rendering lato server un cittadino di prima classe; la pagina di rendering sul lato server è ancora una SPA funzionante quando viene analizzata nel browser client.

— Eliot Sykes
fonte

0

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

Sono fuori dalla vista però che questo richiede due cose:

1) impostazione di tutti i tuoi collegamenti come collegamenti standard di richiesta / risposta al caricamento iniziale, lascia che il tuo framework / libreria SPA li sostituisca con una versione aggiornata (interattiva) una volta caricato il browser e il motore JS identifichi che il supporto SPA è disponibile. Questo è veramente un miglioramento progressivo; JS viene caricato sul sito Web HTML esistente e questo è meglio per i motori di ricerca, le tecnologie assistive e i browser meno recenti.

e

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

C'è un bel po 'di lavoro qui; è vero, ma se hai il controllo su tutto lo stack, le due tecnologie sono bilanciate.

— Crispen Smith
fonte