Búsqueda de sitios web

javascript - ¿Por qué es una mala práctica devolver HTML generado en lugar de JSON? ¿O lo es?

Es bastante fácil cargar contenido HTML desde tus URL/servicios web personalizados usando JQuery u otro framework similar. He usado este enfoque muchas veces hasta ahora y he encontrado el rendimiento satisfactorio.

Pero todos los libros, todos los expertos están tratando de que use JSON en lugar de HTML generado. ¿Qué tan superior es realmente que HTML?

¿Es mucho más rápido?
¿Tiene una carga mucho menor en el servidor?

Por otro lado, tengo algunas razones para usar HTML generado.

  1. Es un marcado simple, y a menudo igual de compacto o incluso más compacto que JSON.
  2. Es menos propenso a errores porque todo lo que obtienes es marcado, y no código.
  3. Será más rápido programar en la mayoría de los casos porque no tendrás que escribir código por separado para el lado del cliente.

¿De qué lado estás y por qué?

Respuesta #1

En realidad, estoy un poco en ambos lados :

  • Cuando lo que necesito del lado de JavaScript es datos, uso JSON
  • Cuando lo que necesito en el lado de JavaScript es presentación sobre la cual no haré ningún cálculo, generalmente uso HTML

La principal ventaja de usar HTML es cuando quieres reemplazar una porción completa de tu página con lo que devuelve la solicitud Ajax:

  • Reconstruir una parte de la página en JS es (bastante) difícil
  • Probablemente ya tengas algún motor de plantillas en el lado del servidor, que se usó para generar la página en primer lugar... ¿Por qué no reutilizarlo?

Generalmente no tomo realmente en consideración el lado del "rendimiento" de las cosas, al menos en el servidor :

  • En el servidor, generar una porción de HTML o algo de JSON probablemente no marcará tanta diferencia
  • Sobre el tamaño de las cosas que pasan por la red: bueno, probablemente no uses cientos de KB de datos/html... Usar gzip en lo que sea que estés transfiriendo es lo que va a hacer la mayor diferencia (no elegir entre HTML y JSON)
  • Una cosa que podría tomarse en consideración, sin embargo, es qué recursos necesitarás en el cliente para recrear el HTML (o la estructura del DOM) a partir de los datos JSON... compáralo con insertar una porción de HTML en la página ;-)

Finalmente, una cosa que definitivamente importa:

  • ¿Cuánto tiempo te tomará desarrollar un nuevo sistema que envíe datos como JSON y codificar el JS necesario para inyectarlo como HTML en la página?
  • ¿Cuánto tiempo tomará solo devolver HTML? ¿Y cuánto si puedes reutilizar parte de tu código del lado del servidor ya existente?

Y para responder a otra respuesta: si necesitas actualizar más de una parte de la página, todavía existe la solución/truco de enviar todas esas partes dentro de una cadena grande que agrupa varias porciones de HTML, y extraer las partes relevantes en JS.

Por ejemplo, podrías devolver alguna cadena que se vea así:

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

Eso no se ve muy bien, pero definitivamente es útil (lo he usado varias veces, principalmente cuando los datos HTML eran demasiado grandes para encapsularlos en JSON) : estás enviando HTML para las partes de la página que necesitan presentación, y estás enviando JSON para la situación en la que necesitas datos...

... Y para extraer esos, el método substring de JS hará el truco, supongo ;-)

Respuesta #2

Principalmente estoy de acuerdo con las opiniones expresadas aquí. Solo quería resumirlas como:

  • Es una mala práctica enviar HTML si terminas analizándolo del lado del cliente para hacer algunos cálculos sobre él.

  • Es una mala práctica enviar JSON si al final lo único que harás será incorporarlo al árbol DOM de la página.

Respuesta #3

Bueno,

Soy una de esas personas raras que le gusta separar las cosas de esta manera: - El servidor es responsable de entregar los datos (modelo); - El cliente es responsable de mostrar (vista) y manipular los datos (modelo);

Entonces, el servidor debería centrarse en entregar el modelo (en este caso JSON es mejor). De esta manera, obtienes un enfoque flexible. Si deseas cambiar la vista de tu modelo, mantienes el servidor enviando los mismos datos y solo cambias el cliente, los componentes de javascript, que convierten esos datos en una vista. Imagina que tienes un servidor entregando datos tanto a dispositivos móviles como a aplicaciones de escritorio.

Además, este enfoque aumenta la productividad, ya que el código del servidor y del cliente se puede construir al mismo tiempo, sin perder nunca el enfoque, que es lo que sucede cuando se sigue cambiando de JS a PHP/JAVA/etc.

En general, creo que la mayoría de las personas prefieren hacer todo lo posible del lado del servidor porque no dominan js, así que tratan de evitarlo tanto como sea posible.

Básicamente, tengo la misma opinión que esos chicos que están trabajando en Angular. En mi opinión, ese es el futuro de las aplicaciones web.

Artículos relacionados