I frontend dei siti Web dovrebbero essere visualizzati sul lato client o sul lato server?

Question

I frontend dei siti Web dovrebbero essere visualizzati sul lato client o sul lato server?

#1 da (4 voti)

5

Ho parlato con un collega che viene da AS3 al mondo HTML . Ha creato un piccolo sito web (non ci sono apparentemente contenuti dinamici) seguendo le regole no-flash per la sua prima volta, e come se possedessi un martello tendi a martellare tutto, ha deciso di creare un framework in JavaScript , in modo che potesse fare tutto "il AS3 modo", con cornici, animazioni di coordinate XY pure e così, per animare i contenuti. Inizialmente la pagina verrebbe caricata completamente, caricando prima la grande quantità di JS e poi la pagina sarebbe accessibile senza modificare l'URL.

Le viste si trasformerebbero in metodi di classe (dove la classe rappresenta una sezione e il metodo rappresenta una vista) che aggiunge testo a una variabile che viene quindi aggiunta a un div. Difende questa situazione con molte ragioni:

I siti Web con una grande quantità di utenti lo fanno per prevenire il sovraccarico del server.
È più facile creare nuove sezioni.
È più facile tradurre, come traduzioni, testi e quasi tutto viene caricato da JSON .
Puoi espandere più sezioni direttamente da un file JSON .
Tutto è scorrevole, poiché non ti sposti su un'altra pagina.

Ora, ecco lo sviluppatore fedele di PHP, che difende il lato opposto. Dico che le viste dovrebbero essere divise in file più piccoli ma contenuti in .php o anche .html file, con la logica di business in un controller e la logica di visualizzazione in questi file. Questo rilascia il client, in quanto può disabilitare JavaScript e mostrare ancora il contenuto senza una questione. Naturalmente il tuo server ha bisogno di fare calcoli, ma è solo il rendering dei file. Alcuni vantaggi potrebbero essere:

Non è necessario caricare l'intero sito Web all'inizio. Pagine web caricate più velocemente.
I tuoi url sono sempre puliti e (nel caso tu lo abbia fatto) amichevoli, senza plugin e lavorando senza problemi nei vecchi browser, mentre ti sposti su un'altra pagina.
Le viste sono conservate in file indipendenti, quindi è più facile lavorare con loro in un team.
Le viste sono normali file html , invece delle chiamate ai metodi che aggiungono le stringhe, quindi modificarle è naturale.
Hai ancora bisogno di PHP (o qualsiasi altra lingua) per caricare i dati da un server (NodeJS non è considerato qui)

E, naturalmente, ecco la vera domanda. Le visualizzazioni dovrebbero essere visualizzate sul lato client o server?

web-development server-side client-side mvc

posta Korcholis 16.04.2013 - 19:16

fonte

1 risposta

Leggi altre domande sui tag web-development server-side client-side mvc

metodo migliore per ripristinare lo stato se si verifica un errore durante l'aggiunta / eliminazione Organizzazione di un repository git con diversi progetti di condivisione del codice

score 4 · Accepted Answer

RobertHarvey ha completamente ragione : dipende. Potrebbe essere una buona soluzione, ma è anche una soluzione terribile per alcuni progetti.

Nella tua domanda dichiari:

He has created a small website (there are apparently no dynamic contents)

Sulla base di ciò ha scelto la soluzione sbagliata. Ora noti anche che ci sono animazioni. Quindi forse, se quelli sono eccezionali, potrebbe essere una buona soluzione. Diciamo che quelle animazioni potrebbero anche essere fatte con soluzioni normali.

Che sia buono o giusto è semplice: se dovesse funzionare come un normale sito Web, quindi con un buon posizionamento nei motori di ricerca, la buona accessibilità e tutti gli altri webdeveloper standard si prendono cura di esso è semplicemente sbagliato. Costruisci un sito Web con un obiettivo. In questo caso: Invita le persone normali a visitarlo per iscriversi / acquistare / visualizzare ecc. Che non raggiungerà tale obiettivo.

I suoi argomenti:

Websites with a high amount of users do this to prevent server overloading.

Sì, ma questo è un piccolo sito web giusto? link

È più facile creare nuove sezioni.

Likely he is unaware of other solutions. No problem, it's his first one. This is something where training / reading could do a lot.

It is easier to translate, as translations, texts and almost everything is loaded from a JSON.

Lo stesso qui, la localizzazione è qualcosa di molto più complesso della semplice traduzione di alcune parti di testo. L'educazione è anche qui la chiave.

You can expand more sections directly from a JSON file.

Potrebbe essere corretto, sembra semplice da fare. Se un utente deve farlo, diventa direttamente più difficile. Ad esempio, con un database potrebbe essere possibile creare un modulo per questo.

Everything is smooth, as you don't move to another page.

Questo è vero ma non annullabile con altre soluzioni. Caricamento di pezzi di contenuto con ajax (con la modifica della cronologia del browser) potrebbe risolvere questo problema. link

Per portarlo a un livello più ampio: non ha senso costruire un framework dedicato se è solo un sito semplice. Usa le basi o un sistema esistente per questo. Dall'altra parte, è una bella esperienza di apprendimento. Abbiamo provato tutti a costruire un CMS una volta, giusto? ;) Le sue argomentazioni non sono forti, se vuole lavorare di più in quest'area sarebbe consigliabile una maggiore conoscenza.