Buena pregunta. Especialmente en tiempos donde cosas como Backbone.js se han vuelto más populares.
Veamos paso a paso.
En primer lugar, la carga en el servidor para producir JSON en lugar de HTML es probablemente más o menos lo mismo. La mayoría de los recursos no entran en la transformación de sus objetos de datos a HTML o JSON, sino que aceptan la solicitud del cliente, cargan su marco, CakePHP en su caso, enrutan la solicitud, cargan algunos componentes más, configuran una conexión de base de datos , lanzándole consultas, aceptando resultados, transformándolos en matrices/objetos y luego solo comenzará a enviar esos datos a cadenas para su vista (JSON o HTML). El asunto es que los lenguajes del lado del servidor como PHP no están realmente impresionados por el bucle de cosas y la salida de valores en cadenas, pueden hacerlo sin dificultad.
En realidad, la diferencia en el rendimiento no será tan buena cuando comience a producir JSON. Al menos, no lo suficientemente grande para la mayoría de las cosas.
Cuando desee utilizar JSON es cuando tiene una pieza compleja de funcionalidad. Por ejemplo, algo así como los feeds de tweetdeck donde hay muchos pequeños componentes y datos que necesitan actualización; Tweets únicos, listas de tweets, recuentos de seguidores, etc. Tiene sentido cargar estos pequeños datos en lugar de volver a descargar juegos completos de HTML cada vez. Utilizaría plantillas JSON y del lado del cliente porque tiene muchas cosas que podrían cambiar.
Sin embargo, en aplicaciones más "normales", como blogs, sitios web de comercio electrónico, wikis, etc., realmente no necesitará cosas tan finas como esta. En ese caso, usarías AJAX (usando tu definición).
La razón de algunos es que es más fácil y más amigable para el desarrollador crear vistas HTML que crear primeras vistas que devuelvan JSON y luego crear plantillas del lado del cliente para renderizarlas. Es más fácil verificar ciertas condiciones, crear bucles, obtener datos adicionales cuando sea necesario, etc. en una plantilla del lado del servidor. De todos modos, no reducirá tu rendimiento.
Otra razón es que puede usar el HTML estático en el lado del servidor para representar páginas que no son AJAX, como una alternativa.Entonces cuando AJAX está disponible para el cliente, usted carga el contenido a través de AJAX y reemplaza, digamos, el contenido de su "con el" del HTML que recibió, pero cuando no hay ningún AJAX disponible, simplemente lo redirige a esa página Por lo tanto, ahora tiene soporte tanto para javascript como para clientes que no son javascript. Usted podría lograr esto también con plantillas del lado del servidor y del cliente, pero eso requeriría un doble trabajo o usar algo como Moustache.
Además de esto, una desventaja de utilizar JSON para hacer toda su representación en el cliente es que se requieren algunas piezas de información para representar su página, pero se supone que no deben estar en manos de sus usuarios. Podría imaginar cosas como datos de tarjetas de crédito, números de seguridad social, nombres reales, etc. que ejecutaría algún tipo de control en su código antes de procesar en el lado del servidor. Para hacer el mismo chequeo en el lado del cliente, debe enviarlo todo al cliente, por lo tanto, dárselo al usuario. Por supuesto, no podría hacer esto y primero procesar todos sus datos en el lado del servidor, antes de enviarlo al cliente, pero eso significa que ya está haciendo más y más de lo que haría en una plantilla HTML de todos modos.
En resumen:
Para mí el rendimiento entre el servidor o la representación HTML del lado del cliente no es tan evidente en la vida real. Uso mucho JSON, pero generalmente para cosas no relacionadas con la vista. Como guardar algo a través de una llamada AJAX y luego devolver un informe de estado en JSON. Así que puedo hacer cosas como if data.status == 'awesome', etc. Sin embargo, si utilizo completamente AJAX un sitio web normal, usaría algo como pjax (abajo) para cargar pedazos de HTML del servidor. En mi opinión, javascript debería estar haciendo cosas con HTML existente y no debería combinarse demasiado. Existen excepciones cuando se crean aplicaciones realmente complejas y en tiempo real que requieren un seguimiento de muchos datos más pequeños al mismo tiempo, por lo que las plantillas del lado del cliente tienen su lugar, pero no solo en todas partes.
Eche un vistazo a pjax, es una biblioteca de JavaScript para cargar piezas de html dinámicamente desde el lado del servidor a los elementos en su página. http://pjax.heroku.com/
DHH respondió a un hilo en Hacker News sobre cómo y qué de su configuración con Basecamp; principalmente scripts del lado del servidor, pequeño cliente MVC.
https://news.ycombinator.com/item?id=3603898
Otro enlace interesante. LinkedIn describe cómo usan plantillas del lado del cliente por motivos de rendimiento. http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
Buena pregunta, aunque pertenece al intercambio de programadores, creo. –
@MichaelDurrant No sé sobre el intercambio de programadores, pero es más una pregunta abierta sí. No estoy muy seguro de cuál es la verdadera 'respuesta', ya que es más una filosofía de programación lo que busca el OP. Tal vez en un foro? Por otra parte, podría imaginarme mirando hacia arriba. ¿Puedo usar mejor las plantillas del lado del cliente o del lado del servidor para mi nueva aplicación? en Stackoverflow y esta pregunta toca eso. – Mosselman
@Purren ha hecho dos preguntas en StackOverflow, esta y otra hace aproximadamente un año y no ha seguido las respuestas. Intente hacerlo ya que mejora la comunidad para ello. – Mosselman