I framework di front-end sono scelte mature e ragionevoli, ma ciò comporta un costo di crawlability e un costo di prestazioni. Questo può o non può essere rilevante, dipende esclusivamente dalla natura del tuo progetto.
Per un sito web, essere in grado di servire direttamente questioni relative ai contenuti HTML. Certo, Google può anche eseguire la scansione dei siti Web resi lato client. Ma altri motori di ricerca no. Ancora più importante, il rendering lato client rende i tuoi contenuti inaccessibili ai crawler dai social network o servizi simili. Quando i visitatori condividono il tuo sito su Facebook, Twitter o Slack, i loro crawler cercano metatag specifici per rendere più di un semplice link. Quando gli utenti vogliono leggere la tua pagina su un servizio read-it-after come Pocket o Instapaper, i loro crawler devono recuperare l'HTML. Non supportare questi casi d'uso limiterà la portata dei tuoi contenuti.
Per un'app Web che non presenta contenuti per utenti non autenticati, la scansione non è rilevante per gli URL della tua app. È ancora importante per le parti statiche visibili pubblicamente.
Quando si esegue il rendering di tutto il lato client, non si deve solo trasmettere la pagina e attendere che il motore di rendering del Browser faccia il suo esempio. Devi trasmettere uno scaffold HTML, tutto il tuo JS, i dati da renderizzare e qualsiasi modello, quindi creare l'HTML e quindi lasciare che il browser esegua il rendering di tutto. Certo, se è possibile utilizzare HTTP / 2 dovendo caricare più risorse non necessariamente porta a problemi di latenza. Ma il cliente dovrà ancora fare più elaborazione. Ciò può ritardare il tempo di caricamento percepito per il caricamento iniziale della pagina. Se questa è un'applicazione web in cui gli utenti sono in qualche modo investiti, questo non importa. Aspetteranno. Per gli utenti occasionali, gli utenti sui telefoni cellulari o per i siti Web il tempo di caricamento iniziale è molto importante. I visitatori potrebbero semplicemente perdere interesse nella tua offerta se non visualizza nulla di utile dopo pochi secondi. Incontro regolarmente siti Web di fantasia lato client che semplicemente non visualizzano nulla perché fanno ipotesi sbagliate.
Si noti che è possibile percepire tempi di caricamento successivi rapidi anche senza utilizzare il rendering lato client. In primo luogo, serve una pagina di rendering lato server. Quindi esegui un piccolo miglioramento progressivo: quando l'utente esegue qualsiasi azione, non lasciare che il browser passi direttamente a quel nuovo URL. Invece, fai fuoco su una richiesta in background per l'URL, visualizza un indicatore di progresso non invadente, attendi fino al termine del download, quindi sostituisci il DOM con l'HTML ricevuto e aggiorna la cronologia del browser. Per esempio. Github fa qualcosa di simile. Oppure puoi semplicemente sostituire parti della pagina con un nuovo frammento HTML, in stile jQuery! Il punto non è che questo sia il modo migliore per fare lo sviluppo web, solo che è un approccio perfetto, molto veloce e altamente compatibile.
Si noti che il rendering lato server non vi tralascia da molti dei vantaggi di rendering lato client. Un frontend lato server può ancora connettersi a un'API (possibilmente su localhost, super veloce!), Può ancora essere sviluppato da un team separato, può ancora fare uso di NPM e così via.
L'unica vera ragione per creare un'app web resa lato client è che l'interazione dell'utente non si adatta facilmente a un modello di trasferimento di stato. Il trasferimento di stato semplifica la modellazione di un flusso di lavoro basato su moduli con un chiaro pulsante "salva modifiche" o interazioni utente che consistono solo in visualizzazione / consumo di contenuto. Pertanto, il rendering lato client è indispensabile se si dispone di uno stato lato client che sarebbe inutile trasferire per ogni interazione dell'utente, ad es. in un editor o in un gioco.