javascript tutorial Applicazione a pagina singola: vantaggi e svantaggi



le funzioni html (9)

Mi piacerebbe rendere il caso per SPA essere il migliore per applicazioni basate su dati. Gmail, ovviamente, è tutto basato sui dati e quindi un buon candidato per una SPA.

Ma se la tua pagina è principalmente per la visualizzazione, ad esempio, una pagina di termini di servizio, allora una SPA è completamente eccedente.

Penso che il punto ideale sia avere un sito con una combinazione di entrambe le pagine SPA e di stile statico / MVC, a seconda della pagina specifica.

Ad esempio, su un sito che sto costruendo, l'utente atterra su una pagina indice MVC standard. Ma poi quando vanno all'applicazione vera e propria, richiama la SPA. Un altro vantaggio è che il tempo di caricamento della SPA non è sulla home page, ma sulla pagina dell'app. Il tempo di caricamento sulla home page potrebbe essere una distrazione per gli utenti del sito per la prima volta.

Questo scenario è un po 'come usare Flash. Dopo alcuni anni di esperienza, il numero di siti Flash è sceso quasi a zero a causa del fattore di carico. Ma come componente di una pagina, è ancora in uso.

Ho letto su SPA e vantaggi. Trovo che la maggior parte di loro non convince. Ci sono 3 vantaggi che suscitano i miei dubbi.

Domanda: puoi agire come avvocato della SPA e dimostrare che ho torto sulle prime tre affermazioni?

                              === ADVANTAGES ===

1. SPA è estremamente buono per siti molto reattivi:

Il rendering lato server è difficile da implementare per tutti gli stati intermedi: gli stati di visualizzazione ridotta non si adattano bene agli URL.

Le app a pagina singola si distinguono per la capacità di ridisegnare qualsiasi parte dell'interfaccia utente senza richiedere un round trip del server per recuperare l'HTML. Ciò si ottiene separando i dati dalla presentazione dei dati avendo un livello di modello che gestisce i dati e un livello di vista che legge dai modelli.

Cosa c'è di sbagliato nel tenere uno strato modello per non SPA? SPA è l'unica architettura compatibile con MVC sul lato client?

2. Con SPA non è necessario utilizzare query aggiuntive sul server per scaricare pagine.

Hah e quante pagine possono scaricare l'utente durante la visita al tuo sito? Due tre? Invece ci sono altri problemi di sicurezza e devi separare la pagina di login, la pagina di amministrazione, ecc in pagine separate. A sua volta è in conflitto con l'architettura SPA.

3. Potrebbero esserci altri vantaggi? Non sentire altro

                            === DISADVANTAGES ===
  1. Il cliente deve abilitare javascript.
  2. Solo un punto di accesso al sito.
  3. Sicurezza.

PS Ho lavorato a progetti SPA e non SPA. E sto facendo quelle domande perché ho bisogno di approfondire la mia comprensione. Nessun mezzo per danneggiare i sostenitori della SPA. Non chiedermi di leggere un po 'di più su SPA. Voglio solo sentire le tue considerazioni al riguardo.


Answer #1

Cerca di non considerare l'utilizzo di una SPA senza prima definire come indirizzerai la sicurezza e la stabilità dell'API sul lato server. Quindi vedrai alcuni dei veri vantaggi dell'utilizzo di una SPA. In particolare, se si utilizza un server RESTful che implementa OAUTH 2.0 per la sicurezza, si otterranno due fondamentali separazioni di preoccupazioni che possono ridurre i costi di sviluppo e manutenzione.

  1. Questo sposterà la sessione (e la sua sicurezza) sulla SPA e alleggerirà il server da tutto questo sovraccarico.
  2. Le tue API diventano sia stabili che facilmente estendibili.

Accennato a prima, ma non reso esplicito; Se il tuo obiettivo è quello di distribuire applicazioni Android e Apple, la scrittura di una SPA JavaScript che è avvolta da una chiamata nativa per ospitare lo schermo in un browser (Android o Apple) elimina la necessità di mantenere sia una base di codice Apple che una base di codice Android.


Answer #2

Capisco che questa è una domanda precedente, ma vorrei aggiungere un altro svantaggio delle applicazioni a pagina singola:

Se si crea un'API che restituisce risultati in una lingua dei dati (come XML o JSON) anziché in un linguaggio di formattazione (come HTML), si attiva una maggiore interoperabilità delle applicazioni, ad esempio nelle applicazioni business-to-business (B2B). Tale interoperabilità offre grandi vantaggi, ma consente alle persone di scrivere software per "estrarre" (o rubare) i dati. Questo particolare svantaggio è comune a tutte le API che utilizzano un linguaggio dati, e non alle ZPS in generale (infatti, una SPA che chiede al server l'HTML pre-renderizzato lo evita, ma a scapito della scarsa separazione tra modello e vista). Questo rischio esposto a questo svantaggio può essere mitigato con vari mezzi, come la limitazione delle richieste e il blocco delle connessioni, ecc.


Answer #3

Svantaggi : tecnicamente, la progettazione e lo sviluppo iniziale della SPA sono complessi e possono essere evitati. Altri motivi per non utilizzare questa SPA possono essere:

  • a) Sicurezza: l'applicazione per pagine singole è meno sicura rispetto alle pagine tradizionali a causa di cross site scripting (XSS).
  • b) Perdita di memoria: la perdita di memoria in JavaScript può persino causare il rallentamento del potente computer. Poiché i siti Web tradizionali incoraggiano a navigare tra le pagine, quindi qualsiasi perdita di memoria causata dalla pagina precedente viene quasi eliminata lasciando meno residui.
  • c) Il client deve abilitare JavaScript per eseguire SPA, ma in un'applicazione multipagina JavaScript può essere completamente evitato.
  • d) SPA cresce a dimensioni ottimali, causa lunghi tempi di attesa. Ad esempio: lavorare su Gmail con una connessione più lenta.

Oltre a ciò, altre limitazioni architetturali sono la perdita dei dati di navigazione, il registro di cronologia di navigazione nel browser e la difficoltà nel test funzionale automatizzato con selenio.

This collegamento spiega i vantaggi e gli svantaggi dell'applicazione singola pagina.


Answer #4

Per aziende come Google, Amazon ecc., I cui server funzionano alla massima capacità in modalità 24/7, ridurre il traffico significa denaro reale: meno hardware, meno energia, meno manutenzione. Cambiare l'utilizzo della CPU da server a client si ripaga e le SPA splendono. I vantaggi sopravanzano gli svantaggi. Quindi, SPA o non SPA dipende molto dal caso d'uso.

Solo per citarne un altro, probabilmente non così ovvio (per gli sviluppatori Web) si usa il caso per SPA: sto cercando un modo per implementare GUI nei sistemi embedded e l'architettura basata su browser mi sembra interessante. Tradizionalmente non c'erano molte possibilità per le interfacce utente nei sistemi embedded - Java, Qt, wx, ecc. O quadri commerciali di proprietà. Alcuni anni fa Adobe ha provato ad entrare nel mercato con il flash, ma sembra non avere così tanto successo.

Oggigiorno, poiché "sistemi embedded" sono potenti come i mainframe alcuni anni fa, un'interfaccia utente basata su browser collegata all'unità di controllo tramite REST è una possibile soluzione. Il vantaggio è che l'enorme tavolozza di strumenti per l'interfaccia utente è gratuita. (ad es. Qt richiede 20-30 $ per unità vendute con diritti di royalty più 3000-4000 $ per sviluppatore)

Per tale architettura la SPA offre molti vantaggi, ad esempio un approccio di sviluppo più familiare per gli sviluppatori di app desktop, accesso ridotto al server (spesso nell'industria automobilistica l'interfaccia utente e gli errori di sistema sono hardware separati, in cui la parte di sistema ha un sistema operativo RT).

Poiché l'unico client è il browser integrato, gli svantaggi menzionati come la disponibilità JS, la registrazione lato server, la sicurezza non contano più.


Answer #5

svantaggi

1. Il cliente deve abilitare javascript. Sì, questo è un chiaro svantaggio di SPA. Nel mio caso, so che posso aspettarmi che i miei utenti abbiano JavaScript abilitato. Se non puoi, allora non puoi fare una SPA, punto. È come provare a distribuire un'applicazione .NET su una macchina senza .NET Framework installato.

2. Solo un punto di accesso al sito. SammyJS questo problema usando SammyJS . 2-3 giorni di lavoro per impostare correttamente il routing e le persone saranno in grado di creare segnalibri deep-link nella tua app che funzionano correttamente. Il tuo server dovrà solo esporre un endpoint - l'endpoint "dammi l'HTML + CSS + JS per questa app" (consideralo come un percorso di download / aggiornamento per un'applicazione precompilata) - e il JavaScript sul lato client che scrivi sarà gestire la voce effettiva nell'applicazione.

3. Sicurezza. Questo problema non è unico per le SPA, devi avere a che fare con la sicurezza esattamente nello stesso modo quando hai un'app client-server "vecchia scuola" (il modello HATEOAS di usare l'ipertesto per collegare le pagine). È solo che l'utente sta facendo le richieste piuttosto che il tuo JavaScript, e che i risultati sono in HTML piuttosto che in JSON o in alcuni formati di dati. In un'applicazione non SPA è necessario proteggere le singole pagine sul server, mentre in un'applicazione SPA è necessario proteggere gli endpoint dei dati. (E, se non vuoi che il tuo client abbia accesso a tutto il codice, devi dividere il codice JavaScript scaricabile anche in aree separate. Lo lego semplicemente al mio sistema di routing basato su SammyJS, quindi il browser richiede solo le cose a cui il client sa che dovrebbe avere accesso, in base al carico iniziale dei ruoli dell'utente, e quindi diventa un non-problema).

vantaggi

  1. Un grande vantaggio architettonico di una SPA (che raramente viene menzionato) in molti casi è l'enorme riduzione della "chattiness" della tua app. Se lo progettate correttamente per gestire la maggior parte dell'elaborazione sul client (l'intero punto, dopotutto), il numero di richieste al server (leggere "possibilità di errori 503 che rovinano la vostra esperienza utente") viene drasticamente ridotto. In effetti, una SPA consente di eseguire l'elaborazione completamente offline, il che è enorme in alcune situazioni.

  2. Le prestazioni sono sicuramente migliori con il rendering lato client se lo fai bene, ma questo non è il motivo più convincente per costruire una SPA. (Dopotutto, le velocità della rete stanno migliorando.) Non basare il caso su SPA su questa base da solo.

  3. La flessibilità nella progettazione dell'interfaccia utente è forse l'altro grande vantaggio che ho trovato. Una volta definita la mia API (con un SDK in JavaScript), sono stato in grado di riscrivere completamente il mio front-end con impatto zero sul server a parte alcuni file di risorse statiche. Prova a farlo con un'app tradizionale MVC! :) (Questo diventa prezioso quando ci si deve preoccupare delle distribuzioni live e della coerenza delle versioni della propria API).

Quindi, in fondo: se hai bisogno di elaborazione offline (o almeno vuoi che i tuoi client siano in grado di sopravvivere a occasionali interruzioni del server) - riducendo drasticamente i costi dell'hardware - e puoi assumere JavaScript e browser moderni, allora hai bisogno di una SPA. In altri casi è più un compromesso.


Answer #6

2. Con SPA non è necessario utilizzare query aggiuntive sul server per scaricare pagine.

Devo ancora imparare molto ma da quando ho iniziato a conoscere SPA, li amo.

Questo particolare punto potrebbe fare un'enorme differenza.

In molte app Web che non sono SPA, vedrai che continueranno a recuperare e ad aggiungere contenuti alle pagine che fanno richieste Ajax. Quindi penso che la SPA vada oltre considerando: cosa succede se il contenuto che verrà recuperato e visualizzato usando ajax è l'intera pagina? e non solo una piccola porzione di una pagina?

Permettetemi di presentare uno scenario. Considera che hai 2 pagine:

  1. una pagina con l'elenco dei prodotti
  2. una pagina per visualizzare i dettagli di un prodotto specifico

Considera che ti trovi nella pagina dell'elenco. Quindi fai clic su un prodotto per visualizzare i dettagli. L'app lato client attiverà 2 richieste Ajax:

  1. una richiesta per ottenere un oggetto JSON con i dettagli del prodotto
  2. una richiesta per ottenere un modello html in cui verranno inseriti i dettagli del prodotto

Quindi, l'app lato client inserirà i dati nel modello html e li visualizzerà.

Quindi si torna all'elenco (non viene eseguita alcuna richiesta per questo!) E si apre un altro prodotto. Questa volta, ci sarà solo una richiesta ajax per ottenere i dettagli del prodotto. Il modello html sarà lo stesso, quindi non è necessario scaricare di nuovo.

Si può dire che in una non SPA, quando apri i dettagli del prodotto, fai solo 1 richiesta e in questo scenario abbiamo fatto 2. Sì. Ma si ottiene il vantaggio da una prospettiva generale, quando si naviga tra molte pagine, il numero di richieste sarà inferiore. Inoltre, i dati trasferiti tra il lato client e il server saranno inferiori perché i modelli html verranno riutilizzati. Inoltre, non è necessario scaricare in tutte le richieste tutti quei file CSS, immagini, javascript presenti in tutte le pagine.

Inoltre, consideriamo che il linguaggio lato server è Java. Se analizzi le 2 richieste che ho menzionato, 1 scarica i dati (non è necessario caricare alcun file di visualizzazione e chiama il motore di visualizzazione della visualizzazione) e gli altri download e il modello HTML statico in modo da poter avere un server Web HTTP che può recuperare direttamente senza dover chiamare il server delle applicazioni Java, nessun calcolo è fatto!

Infine, le grandi aziende utilizzano SPA: Facebook, GMail, Amazon. Non giocano, hanno i più grandi ingegneri che studiano tutto questo. Quindi se non vedi i vantaggi puoi inizialmente fidarti di loro e spero di scoprirli lungo la strada.

Ma è importante usare buoni schemi di progettazione SPA. È possibile utilizzare un framework come AngularJS. Non tentare di implementare una SPA senza utilizzare buoni schemi di progettazione perché si potrebbe finire per avere un disastro.


Answer #7

Diamo un'occhiata a uno dei siti SPA più popolari, GMail.

1. SPA è estremamente buono per siti molto reattivi:

Il rendering lato server non è così difficile come un tempo con semplici tecniche come mantenere un #hash nell'URL o, più recentemente, HTML5 pushState . Con questo approccio lo stato esatto dell'app web è incorporato nell'URL della pagina. Come in GMail ogni volta che apri una mail, un tag hash speciale viene aggiunto all'URL. Se copiati e incollati in un'altra finestra del browser, puoi aprire la stessa email (a condizione che possano autenticarsi). Questo approccio mappa direttamente su una stringa di query più tradizionale, la differenza è semplicemente nell'esecuzione. Con HTML5 pushState () puoi eliminare il #hash e utilizzare URL completamente classici che possono essere risolti sul server alla prima richiesta e quindi caricati tramite ajax su richieste successive.

2. Con SPA non è necessario utilizzare query aggiuntive sul server per scaricare pagine.

Il numero di pagine scaricate dall'utente durante la visita al mio sito web ?? veramente quante mail alcune leggono quando lui / lei apre il suo / suo account di posta. Ho letto> 50 in una volta. ora la struttura delle mail è quasi la stessa. se si utilizzerà uno schema di rendering lato server, il server lo renderà su ogni richiesta (caso tipico). - preoccupazione per la sicurezza - dovresti / non dovresti tenere pagine separate per gli amministratori / login che dipendono interamente dalla struttura del tuo sito prendi paytm.com per esempio anche facendo un sito web SPA non significa che apri tutti gli endpoint per tutti gli utenti intendo che uso i moduli auth con il mio sito web spa. - nel framework SPA più utilizzato Angular JS, il dev può caricare l'intero tempio html dal sito Web in modo che possa essere eseguito a seconda del livello di autenticazione degli utenti. il caricamento preliminare di html per tutti i tipi di autenticazione non è SPA.

3. Possono esserci altri vantaggi? Non sentire altro

  • in questi giorni puoi tranquillamente supporre che il client abbia i browser abilitati per javascript.
  • solo un punto di accesso al sito. Come accennato in precedenza, è possibile eseguire il mantenimento dello stato in modo da poter avere qualsiasi numero di punti di ingresso che si desidera, ma si dovrebbe avere uno di sicuro.
  • anche in un utente SPA si vede solo quello che ha i diritti appropriati. non devi iniettare tutto in una volta. caricamento di modelli diff html e javascript async è anche una parte valida di SPA.

I vantaggi che posso pensare sono:

  1. il rendering HTML richiede ovviamente alcune risorse ora che ogni utente che visita il tuo sito sta facendo questo. inoltre, non solo il rendering delle logiche principali viene ora eseguito lato client anziché lato server.
  2. Problemi di data e ora - Ho appena dato al client l'ora UTC è un formato preimpostato e non mi interessa nemmeno i fusi orari che ho lasciato gestire da javascript. questo è un grande vantaggio per dove ho dovuto indovinare i fusi orari in base alla posizione derivata dall'IP degli utenti.
  3. per me lo stato è più ben mantenuto in una SPA perché una volta che hai impostato una variabile sai che sarà lì. questo dà la sensazione di sviluppare un'applicazione piuttosto che una pagina web. questo aiuta molto tipicamente a realizzare siti come foodpanda, flipkart, amazon. perché se non si utilizza lo stato lato client si stanno utilizzando sessioni costose.
  4. i siti Web sono sicuramente estremamente reattivi - Prenderò un esempio estremo per questo tentativo di creare una calcolatrice in un sito Web non SPA (so che è strano).

Aggiornamenti dai commenti

Non sembra che nessuno abbia parlato di socket e polling lungo. Se si effettua il logout da un altro client, ad esempio l'app mobile, è necessario disconnettersi anche dal browser. Se non si utilizza SPA, è necessario ricreare la connessione socket ogni volta che è presente un reindirizzamento. Questo dovrebbe funzionare anche con eventuali aggiornamenti di dati come notifiche, aggiornamento del profilo ecc

Una prospettiva alternativa: a parte il tuo sito web, il tuo progetto coinvolgerà un'app mobile nativa? In caso affermativo, è probabile che si inviino dati grezzi a tale app nativa da un server (ad es. JSON) e si esegua l'elaborazione lato client per il rendering, correggere? Quindi con questa affermazione, stai GIÀ facendo un modello di rendering lato client. Ora la domanda diventa, perché non dovresti usare lo stesso modello per la versione del tuo sito web? Tipo di un gioco da ragazzi. Quindi la domanda diventa se vuoi rendere le pagine lato server solo per i vantaggi SEO e la convenienza degli URL condivisibili / condivisibili


Answer #8

Uno dei principali svantaggi di SPA - SEO. Solo recentemente Google e Bing hanno iniziato a indicizzare le pagine basate su Ajax eseguendo JavaScript durante la scansione e, in molti casi, le pagine vengono indicizzate in modo errato.

Durante lo sviluppo di SPA, sarai costretto a gestire i problemi di SEO, probabilmente post-rendering di tutto il tuo sito e creazione di istantanee html statiche per l'utilizzo del crawler. Ciò richiederà un solido investimento in infrastrutture adeguate.

Aggiornamento 19.06.16:

Da quando ho scritto questa risposta qualche tempo fa, acquisisco molta più esperienza con le app a singola pagina (ovvero, AngularJS 1.x) - quindi ho più informazioni da condividere.

A mio avviso, il principale svantaggio delle applicazioni SPA è il SEO, che li rende limitati al tipo di app "dashboard". Inoltre, si avranno tempi molto più difficili con il caching, rispetto alle soluzioni classiche. Ad esempio, nel caching di ASP.NET è estremamente semplice: basta attivare OutputCaching e si sta bene: l'intera pagina HTML verrà memorizzata nella cache in base all'URL (oa qualsiasi altro parametro). Tuttavia, in SPA dovrai gestire il caching da solo (utilizzando alcune soluzioni come cache di secondo livello, cache dei template, ecc.).





single-page-application