Generación de marcado HTML: lado del cliente vs. Lado del Servidor, ¿tu perspectiva?

Question

Para evitar actualizaciones de página en aplicaciones web, hay dos formas de generar el marcado

a) Realice una llamada Ajax, genere el marcado (HTML) en el servidor y devuélvala como respuesta, manipule el DOM con el nuevo contenido en el lado del cliente.

b) Realice una llamada Ajax que devuelva datos en formato JSON, en el lado del cliente utilice el motor de plantillas y javascript para actualizar el DOM.

Puedo pensar en las siguientes consideraciones, ¿cuál es su opinión/experiencia con estas alternativas?

1) Idioma: Para el enfoque A anterior, puede programar en el idioma que desee en el lado del servidor. El enfoque B requiere JavaScript.

2) La reutilización de aplicación del lado del servidor: JSON llamadas resintonización tiene más capacidad de reutilización con comparar a devolver llamadas marcado HTML (esto no es realmente un problema si no hay consumidores fuera de la aplicación)

P, S. : 1) Hay una pregunta similar aquí - Creating HTML: PHP server-side vs. jQuery client-side. En mi caso, sugiero usar un motor de plantillas del lado del cliente como tmpt, ejs.

2) Tanto en el servidor como en el lado del cliente, planeo usar el patrón MVC.

Answer 1

Nuevamente, la respuesta correcta se basa en la situación.

Si está alimentando datos a un widget del lado del cliente, como un autocompletar, o una tabla de datos, entonces JSON es la manera de hacerlo. Alimente los datos lo más crudo posible para que el componente en cuestión lo pueda digerir fácilmente.

Si simplemente muestra datos, o abre una página en un cuadro de diálogo, sugiero usar el lado del servidor para compilar el HTML. No permita que el método de transferencia de datos cambie la forma en que normalmente generaría el HTML. Si normalmente haría que el servidor compilara el código HTML, no permita que el hecho de que una solicitud AJAX lo solicite cambie su decisión. innerHTML es una forma extremadamente eficiente y efectiva de obtener rápidamente HTML en el DOM.

Answer 2

En realidad, ambas opciones requieren JavaScript, ya que necesita JS para Ajax.

He utilizado ambos enfoques, y realmente depende de su aplicación. No creo que 'en general' uno sea mejor que el otro. Algunos pensamientos:

• Si usted decide hacer plantillas, sugeriría jQuery tmpl, y animo a probar http://knockoutjs.com/
• Si decide HTML devuelva, asegúrese de que usted no tiene JavaScript en aquellos parciales. Llegué a un equipo que estaba haciendo eso y causa un sinfín de problemas.

Answer 3

Yo diría que depende de para qué es esa llamada ajax.

Si realiza adiciones o cambios bastante sustanciales a una página, haga que el ajax devuelva el marcado finalizado.

Si realiza pequeños cambios en varias áreas de la página, devuélvala en say json y haga las manipulaciones del lado del cliente.

Todo se reduce a propósito, pero en cualquier caso, es necesario el soporte de javascript (la respuesta deberá ser idéntica sin importar cuál sea el idioma del lado del servidor).

Answer 4

Creo que se reduce a su zona de confort. Uso ASP.NET MVC y he trabajado con ambos enfoques. En mi experiencia, la generación de marcado del lado del servidor tiende a ser más clara y más fácil de depurar. Cada vez que divide una operación de visualización entre el cliente y el servidor, está introduciendo complejidad. Creo que la simplicidad es un atributo de calidad de software muy infravalorado hoy en día.

En ASP.NET MVC, el código del lado del servidor sigue convenciones conocidas en su organización, tiene un buen soporte de depurador e integración de herramientas.

Por el contrario, si bien existen mejores prácticas, la organización de código JavaScript se basa a menudo en las opiniones del desarrollador individual. Tiendo a usar Firebug para la depuración de JS. No encuentro el depurador VS mucho mejor para el lado del cliente. Ambos no están a la par con la depuración del servidor.

Teniendo esto en cuenta, tiendo a favorecer la generación de marcado del lado del servidor, pero uso AJAX cuando necesita para. Cada vez que divide las operaciones de visualización entre el servidor y el cliente, está introduciendo complejidad y dificultando el mantenimiento y la depuración.

En cuanto a devolver JSON para "reutilización", llamaría a YAGNI. En primer lugar, devolver el marcado significa que la operación es más atómica en el lado del servidor y AJAX en el lado del cliente para recuperarla más simple. En segundo lugar, si realmente necesita la implementación de JSON, es una refactorización fácil.

Para concluir, trato de usar una regla empírica: "¿Cuánto tardaría un nuevo desarrollador de 'promedio de joe' en comprender y realizar cambios en este código?" Todo lo que hagas para acortar ese período de tiempo probablemente sea algo bueno a largo plazo.