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

json_decode javascript

Question

Es bastante fácil cargar contenido HTML desde sus URL / servicios web personalizados utilizando JQuery o cualquier otro marco similar. He usado este enfoque muchas veces y hasta ahora y encontré el rendimiento satisfactorio.

Pero todos los libros, todos los expertos están intentando que yo use JSON en lugar de HTML generado. ¿Cómo es mucho más superior 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, ya menudo tan compacto o en realidad más compacto que JSON.
2. Es menos propenso a errores porque todo lo que está obteniendo es un marcado, y no código.
3. En la mayoría de los casos, la programación será más rápida, ya que no tendrá que escribir el código por separado para el cliente.

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

Answer 1

Bien,

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

Por lo tanto, el servidor debe centrarse en entregar el modelo (en este caso, JSON es mejor). De esta manera obtendrá un enfoque flexible. Si desea cambiar la vista de su modelo, mantiene el servidor enviando los mismos datos y solo cambia el cliente, los componentes de JavaScript, que cambian esos datos a una vista. Imagínese, usted tiene un servidor que entrega datos a dispositivos móviles, así como a aplicaciones de escritorio.

Además, este enfoque aumenta la productividad, ya que el servidor y el código del cliente pueden construirse al mismo tiempo, sin perder el enfoque, que es lo que sucede cuando se cambia de js a PHP / JAVA / etc.

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

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

Answer 2

Creo que depende de la estructura del diseño, es más atractivo usar JSON que HTML, pero la pregunta es cómo manejarlo para que se pueda mantener fácilmente.

Por ejemplo, digamos que tengo la página de listado que utiliza el mismo html / estilo de todo el sitio, escribiría la función global para formatear esas partes de HTML y todo lo que tengo que hacer es pasar el objeto JSON a la función.

Answer 3

Depende de las circunstancias.

A veces es esencial evitar JSON. Cuando nuestros programadores tienen problemas para programar en js, por ejemplo.

Mi experiencia me dice que: mejor uso del servicio ajax que en línea JSON.

Tarde o temprano el js se convierte en un problema.

Answer 4

Dependiendo de su interfaz de usuario, es posible que necesite actualizar dos (o más) elementos diferentes en su DOM. Si su respuesta está en HTML, ¿va a analizar eso para averiguar qué va a dónde? O simplemente puedes usar un hash JSON.

Incluso puede combinarlo, devolver un JSON con datos html :)

{ ''dom_ele_1'' : ''<p>My HTML part 1</p>'', ''dome_ele_2'' : ''<div>Your payment has been received</div>'' }

Answer 5

El envío de json generalmente se realiza cuando tiene un widget de javascript que solicita información del servidor, como una lista o una vista de árbol o un autocompletado. Esto es cuando enviaría JSON, ya que son datos que se analizarán y utilizarán en bruto. Sin embargo, si solo va a mostrar HTML, es mucho menos trabajo generar el servidor y mostrarlo en el navegador. Los navegadores están optimizados para insertar HTML directamente en el dom con innerHTML = "", por lo que no puedes equivocarte con eso.

Answer 6

Estoy principalmente de acuerdo con las opiniones expresadas aquí. Solo quería resumirlos 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 todo lo que terminará haciendo es incorporarlo al árbol DOM de la página.

Answer 7

Estoy un poco en ambos lados, en realidad:

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

La principal ventaja de usar HTML es cuando desea reemplazar una parte completa de su página con lo que se obtiene de la solicitud de Ajax:

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

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

• En el servidor, generar una parte de HTML o algún JSON probablemente no supondrá una gran diferencia.
• Sobre el tamaño de las cosas que pasan por la red: bueno, probablemente no use cientos de KB de datos / html ... Usar gzip en lo que esté transfiriendo es lo que hará la mayor diferencia (no elegir entre HTML y JSON)
• Sin embargo, una cosa que podría tenerse en cuenta es qué recursos necesitará en el cliente para recrear el HTML (o la estructura DOM) de los datos JSON ... compare eso con insertar una parte de HTML en la página; -)

Finalmente, una cosa que definitivamente importa:

• ¿Cuánto tiempo le llevará desarrollar un nuevo sistema que enviará datos como el código JSON + que JS requirió para inyectarlo como HTML en la página?
• ¿Cuánto tiempo tomará devolver solo HTML? ¿Y por cuánto tiempo si puede reutilizar parte de su código de servidor ya existente?

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

Por ejemplo, podría devolver una cadena que se parece a esto:

<!-- 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 es definitivamente útil (lo he usado un par de veces, principalmente cuando los datos HTML eran demasiado grandes para ser encapsulados en JSON) : está enviando HTML para las partes de la página que necesita presentación, y está enviando a JSON para la situación en la que necesita datos ...

... Y para extraerlos, el método de subcadena JS hará el truco, supongo ;-)

Answer 8

HTML tiene muchos datos redundantes y no se muestran, es decir, etiquetas, hojas de estilo, etc. Por lo tanto, el tamaño HTML en comparación con los datos JSON será mayor, lo que conlleva más tiempo de descarga y renderización, y también hará que el navegador esté ocupado al procesar los nuevos datos.

Answer 9

IMV, se trata de separar los datos de la presentación de los datos, pero estoy con Pascal, no necesariamente se deduce que esa separación solo puede ser a través del límite cliente / servidor. Si ya tiene esa separación (en el servidor) y solo quiere mostrar algo al cliente, ya sea que envíe JSON y lo procese en el cliente, o simplemente envíe HTML, depende totalmente de sus necesidades. Decir que está "equivocado" al enviar HTML de nuevo en el caso general es simplemente una declaración IMV.

Answer 10

JSON es un formato muy versátil y ligero. Descubrí su belleza cuando comencé a usarlo como datos del analizador de plantillas del lado del cliente. Permítanme explicar, mientras que antes de usar smarty y las vistas en el lado del servidor (generando una alta carga en el servidor), ahora uso algunas funciones de jquery personalizadas y todos los datos se representan en el lado del cliente, usando el navegador de clientes como analizador de plantillas. ahorra recursos del servidor y, por otro lado, los navegadores mejoran sus motores JS todos los días. Por lo tanto, la velocidad de análisis del cliente no es un tema importante en este momento; aún más, los objetos JSON son usualmente muy pequeños, por lo que no consumen muchos recursos del lado del cliente. Prefiero tener un sitio web lento para algunos usuarios con un navegador lento en lugar de un sitio lento para todos debido a un servidor muy cargado.

Por otro lado, al enviar datos puros desde el servidor, se los abstrae de la presentación, por lo que si mañana desea cambiarlos o integrar sus datos en otro servicio, puede hacerlo mucho más fácilmente.

Sólo mis 2 centavos.

Answer 11

La respuesta HTML es suficiente en la mayoría de los casos, a menos que tenga que realizar algún cálculo en el lado del cliente.

Answer 12

Si desea un cliente limpio desacoplado, que en mi opinión es la mejor práctica, entonces tiene sentido tener el 100% del DOM creado por javascript. Si crea un cliente basado en MVC que tiene todo el conocimiento para construir la interfaz de usuario, sus usuarios descargarán un archivo javascript una vez y se almacenarán en caché en el cliente. Todas las solicitudes posteriores a esa carga inicial están basadas en Ajax y solo devuelven datos. Este enfoque es el más limpio que he encontrado y proporciona una encapsulación independiente limpia de la presentación.

El lado del servidor entonces simplemente se centra en la entrega de datos.

Así que mañana, cuando el producto le pida que cambie el diseño de una página por completo, todo lo que cambia es la fuente JS que crea el DOM, pero es probable que pueda reutilizar sus controladores de eventos ya existentes y el servidor es ajeno porque está 100% desconectado de la presentación.

Answer 13

Si la respuesta no necesita más procesamiento del lado del cliente, HTML está bien en mi opinión. Enviar JSON solo te obligará a hacer ese procesamiento del lado del cliente.

Por otro lado, uso JSON cuando no quiero usar todos los datos de respuesta a la vez. Por ejemplo, tengo una serie de tres selecciones encadenadas, donde el valor seleccionado de uno determina qué valores se van a utilizar para completar el segundo, y así sucesivamente.

Answer 14

Tengo algo interesante que pensé añadir. Desarrollé una aplicación que solo cargaba una vez una vista completa. Desde ese momento en adelante, se comunicó al servidor solo con ajax. Solo se necesita cargar una página (mi razón para esto no es importante aquí). La parte interesante viene en que tuve una necesidad especial de devolver algunos datos para ser operados en el javascript Y una vista parcial para ser mostrada. Podría haber dividido esto en dos llamadas a dos métodos de acción separados, pero decidí ir con algo un poco más divertido.

Echale un vistazo:

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

¿Qué es RenderPartialViewToString () que puede preguntar? Es este pequeño nugget de frescor aquí:

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

No he realizado ninguna prueba de rendimiento en esto, por lo que no estoy seguro de si incurre en más o menos sobrecarga que llamar a un método de acción para el JsonResult y uno para el ParticalViewResult, pero todavía pensé que era bastante bueno. Simplemente serializa una vista parcial en una cadena y la envía junto con el Json como uno de sus parámetros. Luego uso JQuery para tomar ese parámetro y colocarlo en su nodo DOM apropiado :)

Déjame saber lo que piensas de mi híbrido!