Buona domanda. Soprattutto nei momenti in cui cose come Backbone.js stanno diventando sempre più popolari.
Vediamolo passo dopo passo.
In primo luogo, il carico sul server per produrre JSON piuttosto che HTML è probabilmente più o meno lo stesso. La maggior parte delle risorse non vanno a trasformare gli oggetti dati in HTML o JSON, ma accettano la richiesta del client, caricando il framework, CakePHP nel tuo caso, instradando la richiesta, caricando altri componenti, impostando una connessione al database , lanciando query su di esso, accettando i risultati, trasformandoli in matrici/oggetti e solo dopo inizierai a esportare tali dati in stringhe per la tua visualizzazione (JSON o HTML). Il problema è che i linguaggi lato server come PHP non sono veramente impressionati dall'introduzione di elementi e dall'immissione di valori in stringhe, ma possono farlo senza difficoltà.
In realtà, la differenza di prestazioni non sarà eccezionale se inizi a emettere JSON. Almeno, non abbastanza grande per la maggior parte delle cose.
Quando si desidera utilizzare JSON è quando si dispone di una funzionalità complessa. Ad esempio qualcosa come i feed di tweetdeck dove ci sono molti piccoli componenti e pezzi di dati che devono essere aggiornati; Singoli tweets, elenchi di tweet, conteggi follower, ecc. Ha senso caricare queste piccole informazioni piuttosto che riscaricare nuovamente set completi di HTML ogni volta. Utilizzerai i modelli JSON e client side perché hai molte cose che potrebbero potenzialmente cambiare.
In altre applicazioni "normali", tuttavia, come blog, siti di e-commerce, wiki, ecc. Non avrete davvero bisogno di cose a grana fine come questa. In questo caso useresti AJAX (usando la tua definizione).
Il motivo per alcuni è che è più facile e più facile da sviluppare sviluppare viste HTML piuttosto che creare viste che restituiscano JSON e quindi costruendo modelli lato client per renderle. È più facile controllare determinate condizioni, creare loop, recuperare dati extra quando necessario, ecc. In un template lato server. Non taglierà comunque la tua performance in ogni caso.
Un altro motivo è che è possibile utilizzare l'HTML statico sul lato server per eseguire il rendering di pagine non AJAX come ripiego.Quindi, quando AJAX è disponibile per il client, si carica il contenuto tramite AJAX e si sostituisce si consente di dire il contenuto del proprio '' con il '' dall'HTML che si è ottenuto, ma quando non c'è AJAX disponibile, basta reindirizzare a quella pagina. Quindi ora hai il supporto per entrambi i client javascript e non-javascript. È possibile ottenere questo risultato anche con il template server e sul lato client, ma ciò richiederebbe un doppio lavoro o l'utilizzo di qualcosa come Moustache.
Oltre a ciò, uno svantaggio dell'utilizzo di JSON per eseguire tutto il rendering nel client è che alcune informazioni sono necessarie per il rendering della pagina, ma non dovrebbero essere nelle mani degli utenti. Potrei immaginare cose come dati di carte di credito, numeri di previdenza sociale, nomi reali, ecc. Che eseguiresti una sorta di controllo nel tuo codice prima di eseguire il rendering sul lato server. Per fare lo stesso controllo sul lato client, dovresti inviarlo tutto al cliente, ergo dandogli all'utente. Ovviamente non è possibile farlo e prima elaborare tutti i dati sul lato server, prima di inviarlo al client, ma ciò significa che stai già facendo sempre di più di quello che faresti comunque in un modello HTML.
Per riassumere:
Per me le prestazioni tra server o il rendering lato client HTML non è così evidente nella vita reale. Io uso un sacco di JSON, ma di solito per cose non vista. Come salvare qualcosa tramite una chiamata AJAX e quindi restituire un rapporto di stato in JSON. Quindi posso fare cose del tipo if data.status == 'awesome', ecc. Se invece avessi completamente AJAX come un normale sito web, userei qualcosa come pjax (sotto) per caricare pezzi di HTML dal server. Ai miei occhi javascript dovrebbe fare cose con l'HTML esistente e non dovrebbe essere accoppiato troppo con esso. Ci sono delle eccezioni, quando si creano applicazioni veramente complesse e in tempo reale che richiedono di tenere traccia di molti più piccoli pezzi di dati allo stesso tempo, quindi la templatura lato client ha il suo posto, ma non solo ovunque.
Dai un'occhiata a pjax, è una libreria javascript per il caricamento di pezzi di html dinamicamente dal lato server in elementi sulla tua pagina. http://pjax.heroku.com/
DHH ha risposto alla discussione su Hacker News sul come e cosa della loro messa a punto con Basecamp; per lo più script lato server, piccolo client MVC.
https://news.ycombinator.com/item?id=3603898
Un altro link interessante. LinkedIn descrive come utilizzano i template sul lato client per motivi di prestazioni. http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
Buona domanda - appartiene allo scambio di programmatori anche se credo. –
@MichaelDurrant Non so dello scambio di programmatori, ma è più di una domanda aperta sì. Non sono abbastanza sicuro di quale sia la vera 'risposta' dal momento che è più una filosofia di programmazione che l'OP sta cercando. Forse su un forum? Poi di nuovo, potrei immaginare di guardare in alto 'Posso usare meglio il template sul lato client o sul lato server per la mia nuova app?' su Stackoverflow e questa domanda tocca questo. – Mosselman
@Purren hai posto due domande su StackOverflow, questa e un'altra circa un anno fa e non hai seguito le risposte. Prova a farlo perché rende la comunità migliore per questo. – Mosselman