Quali vantaggi vengono conferiti utilizzando il rendering della pagina sul lato server?

Rendering HTML lato server:

• Rendering del browser più veloce
• Il caching delle pagine è possibile come un aumento delle prestazioni rapido e sporco
• Per le app "standard", molte funzioni dell'interfaccia utente sono predefinite
• A volte considerato più stabile perché i componenti sono solitamente soggetti a convalida in fase di compilazione
• si appoggia sull'esperienza di back-end
• A volte più veloce da sviluppare *

* Quando i requisiti dell'interfaccia utente si adattano bene al framework.

Rendering HTML lato client:

• Utilizzo della larghezza di banda inferiore
• Il rendering della pagina iniziale è più lento. Potrebbe non essere nemmeno visibile nei moderni browser desktop. Se hai bisogno di supportare IE6-7, o molti browser mobili (il webkit mobile non è male) potresti incontrare colli di bottiglia.
• Building API-first significa che il client può facilmente essere un'app proprietaria, thin client, un altro servizio web, ecc.
• Si appoggia sull'esperienza JS
• A volte più veloce da sviluppare **

** Quando l'interfaccia utente è ampiamente personalizzata, con interazioni più interessanti. Inoltre, trovo che la codifica nel browser con il codice interpretato sia notevolmente più veloce dell'attesa per la compilazione e il riavvio del server.

Potresti anche considerare un modello ibrido con un'implementazione light backend usando un sistema di template front-end / back-end come baffi .

Generazione HTML lato server:

• più facile eseguire il debug;
• nessun problema con la compatibilità del browser;
• con la classica generazione lato server a pagina intera è più difficile memorizzare nella cache HTML, anche se ha parti invariabili di grandi dimensioni; (la soluzione è recuperare i frammenti HTML tramite chiamate AJAX);
• non sfruttare i proxy di memorizzazione nella cache e i CDN per HTML dinamico;

Generazione HTML lato client:

• più difficile eseguire il debug;
• alcuni problemi con i browser obsoleti;
• nessun problema nella cache dei modelli HTML lato client;
• sfruttando i proxy di memorizzazione nella cache e i CDN per i modelli HTML e il codice JS;
• utilizzo della rete molto inferiore;

Nota che la generazione lato client è il modo in cui viene eseguita in caso di siti mobili di successo, poiché apparentemente è più efficiente con i browser moderni (i browser basati su WebKit hanno circa il 70-80% del mercato mobile).

LinkedIn ha un articolo sui vantaggi dell'approccio lato client usando dust.js come esempio : "Lasciando le JSP in polvere: spostando LinkedIn in dust.js template lato client "

Dipende da quali sono i tuoi requisiti. Se hai bisogno di una soluzione ad alte prestazioni, a bassa latenza che dipende da molte piccole attività, puoi utilizzare una struttura simile a quella che descrivi. Tuttavia, le soluzioni più comuni, in Java, PHP e C # non sono predefinite.

La maggior parte delle applicazioni Web dipende molto dai database, la maggior parte dei quali è tale che le pagine non possono eseguire il rendering senza almeno una chiamata. Ovviamente non vuoi esporre pubblicamente il tuo database, per diversi motivi:

• Sicurezza (come Oded cita) - tu sicuramente non vuoi esporre pubblicamente la tua rete! Idealmente l'unica interfaccia verso i tuoi sistemi dall'esterno dovrebbe essere https al tuo server.
• Facilità di sviluppo: davvero, veramente , davvero non vuoi scrivere SQL in Javascript e le lingue progettate per il web la presentazione non funziona bene con gli RDB. Non hanno concetto di stato, per esempio.

Quindi, quando hai bisogno di un database, usi linguaggi che giocano con loro come Java, C #, PHP, ecc. Il modo più semplice per generare una pagina risulta essere il seguente: tu usi una lingua di template (la maggior parte notoriamente PHP, ma JSP e ASP sono altri due linguaggi molto comuni) per costruire la pagina. Il linguaggio fornisce costrutti che richiamano altri moduli. In PHP questo è comunemente nella pagina o in un altro file PHP, usando il pattern MVC. In JSP si usano scriptlet o JSP Expression Language. Questi altri moduli sono in grado di connettersi al DB, eseguire la logica e restituire valori al livello di vista. Il risultato finale è una pagina HTML generata, resa sul server e inviata al client.

Quando il tuo database si trova sulla stessa rete del tuo renderer di pagine, ottieni anche prestazioni migliori. Il cliente deve solo fare una richiesta e ricevere una pagina - potrebbe essere necessario fare 10-15 richieste DB prima di avere tutte le informazioni di cui l'utente ha bisogno. Una latenza di millisecondi sulla rete sarebbe di pochi secondi se il cliente dovesse eseguirli tutti.

Quando i sistemi diventano più grandi, la separazione delle preoccupazioni e delle competenze fondamentali diventa cruciale. HTML è buono per la visualizzazione. Javascript è buono per i contenuti dinamici. SQL è ottimo per interrogare un database e altri linguaggi sono validi per la logica aziendale. Il nostro compito come sviluppatori è quello di utilizzare tutti gli strumenti a nostra disposizione per costruire un sistema gestibile. La facilità di sviluppo è una parte enorme di un buon sistema. Nella mia mente, è importante quasi quanto le prestazioni e l'usabilità. I grandi sistemi si evolvono nel tempo. I sistemi scadenti sono stati scritti male fin dall'inizio e non sono mai stati migliorati.

I client mobili sono in genere di potenza, larghezza di banda e limiti di memoria. Probabilmente è meglio rendere pagine per loro sul server.

Per i client desktop potresti prendere in considerazione l'invio di js + json per rendere la pagina sul client, renderla aggiornabile dinamicamente, ecc.

Un enorme vantaggio del rendering lato server è l'accessibilità - le app basate su javascript sono ancora un grosso problema per le persone senza vista. Quello e c'è questo ragazzo cieco chiamato "googlebot" che potresti voler soddisfare. Non fa javascript così bene.