¿Cuándo debe JavaScript generar HTML?

Intento generar la menor cantidad de HTML posible de JavaScript. En cambio, prefiero manipular el marcado existente siempre que puedo y solo generar HTML cuando necesito insertar dinámicamente un elemento que no es un buen candidato para usar Ajax. Esto, creo, hace que sea mucho más fácil mantener el código y hacer cambios rápidamente porque el marcado es más fácil de leer y rastrear. Mi regla general es: HTML es para la estructura del documento, CSS es para la presentación, JavaScript es para el comportamiento.

Sin embargo, he visto mucho código JS que genera montones de HTML, incluidos formularios completos y diálogos modales con mucho contenido. En general, ¿qué método se considera mejor práctica? ¿En qué circunstancias se debe usar JavaScript para generar HTML y cuándo no?

Cada vez que me encuentro con una gran generación de HTML en JavaScript, era casi exclusivamente en un complemento de interfaz de usuario independiente. Tiene sentido, ya que permite encapsular todo el complemento en un solo archivo .js (+ a .css para personalizar estilos), lo que lo hace fácilmente reutilizable, distribuible e independiente del marco utilizado en la aplicación.

Entonces, si está escribiendo un complemento de JavaScript independiente o un componente de interfaz de usuario genérico que le gustaría usar en diferentes aplicaciones, este enfoque tiene sus ventajas. De lo contrario, creo que es más limpio, más fácil de escribir y más fácil de mantener cuando mantiene la generación html lejos de JavaScript y en el lado del servidor.

Creo que el problema es que está comparando plantillas del lado del servidor escritas de forma limpia con una generación HTML del lado del cliente ad-hoc mal escrita. Por supuesto, el código limpio es más fácil de leer, mantener y rastrear.

Usted llama al código del lado del cliente "montículos de HTML", pero, por supuesto, es el mismo HTML donde se genera. El "montículo" es realmente el gran trozo de código.

Existen muchas bibliotecas de plantillas del lado del cliente. Funcionan de manera similar a las del lado del servidor. En cuanto a lo que debería preferir, la compensación del rendimiento es complicada, pero JSON suele ser más compacto que el HTML en que se convierte y tener la plantilla en el cliente puede eliminar algunas llamadas al servidor. Por otro lado, el cliente puede tener JS deshabilitado o ser demasiado lento para ser práctico, por lo que también depende de su público objetivo. En general, creo que los enfoques son bastante comparables, siendo el factor más importante las capacidades del navegador de su público objetivo.

Pero depende exactamente de lo que esté haciendo, si prefiere JS a su entorno de servidor, qué solución de plantilla prefiere, etc.

Existe una tendencia a usar plantillas del lado del cliente, en el caso extremo de que el servidor proporcione solo API RESTful, por ejemplo, en formato JSON, mientras que hace todo el procesamiento del lado del cliente. La ventaja de ese enfoque es que el código y las plantillas JS son recursos estáticos que pueden almacenarse en caché, representarse y distribuirse a través de CDN. Lo que no se puede hacer si tiene HTML dinámico generado por el lado del servidor. Además, devolver solo datos de RESTful API en formato ligero utiliza muchos menos recursos del lado del servidor, lo que agiliza la respuesta. Además, al ser más liviano, es menos transferencia de red, lo que nuevamente lo hace más rápido. De esta forma, puede tener una aplicación de baja latencia muy receptiva incluso en conexiones lentas como 3G. Por lo tanto, este enfoque es popular para páginas y aplicaciones móviles.

Hay numerosas librerías que implementan las plantillas JS, uno de los más populares son puro , bigote y dust.js . Más tarde es utilizado por LinkedIn, describieron las ventajas en su artículo "Dejar las JSP en el polvo: mover LinkedIn a las plantillas del lado del cliente dust.js" .

La ventaja de generar HTML en el cliente es que descarga el trabajo de representación a cada cliente, que generalmente permanece inactivo esperando la respuesta. Liberando más recursos del servidor para entregar solo datos JSON y contenido estático (HTML, JS y CSS).

Hacemos una aplicación web que genera exclusivamente HTML con Javascript. El 87% de las visitas al servidor son datos JSON, el contenido estático generalmente se carga una vez, luego desde la memoria caché del navegador.

Pero no puede usarlo, al menos no fácilmente, si necesita SEO. O si se dirige a una población que tiene Javascript deshabilitado, pero no estoy seguro de que este todavía sea relevante con Youtube, Twitter, Facebook, Gmail, ... naturalmente obligando a las personas a habilitarlo.

Con respecto a la carga dinámica de páginas, uno debe darse cuenta de que detrás de todo "JQuery AJAX Cloud!" magia, solo están sucediendo dos cosas posibles:

1. El código de un elemento se inyecta en un div (incorrecto) o
2. El contenido se está cargando en un iframe (mejor, pero no es lo mismo ...)

En cuanto a la pregunta original, solamente puedo crear contenido HTML a través de Javascript cuando estoy creando una aplicación web de algún tipo que lee XML o JSON datos almacenados en el servidor, y se pone cambiado mucho.

No tendría mucho sentido para cargar el contenido estático en una página con Javascript, ya que siempre existe la posibilidad de que no se carga bien, o el cliente tendrá que desactivado ( "Take That anuncios molestos!"). Además, hace que sea muy difícil de cambiar el contenido HTML cuando se smushed dentro de un feo document.write()o una cadena de document.createElement()'s.

Por lo tanto, usted tiene razón; o bien escribir el HTML puro, o si el contenido dinámico-ish es necesario, utilice un script del servidor del lado de salida a lo que sea necesario. Uso Javascript para inyectar HTML sólo si el sitio está destinado a trabajar sin una conexión a Internet, o un caso similar.

Una última nota, si desea implementar xmlhttprequests, er, AJAX, en un sitio web, probablemente la mejor / más segura forma de hacerlo es almacenar los datos en un formato de datos (como XML), cargarlos y enviarlos en consecuencia en el cliente document.writey element.innerHTMLrealmente no es la mejor manera de manipular el contenido, y seguramente causará posibles dolores de cabeza en el futuro (¿por qué no se ejecuta este script? ¡Mi <i>etiqueta rota está en cursiva todo! etc.).

Mi mantra sobre eso es: cuando es más fácil y a nadie le importa el marcado.

También puede aprovechar ambos y definir un límite donde es demasiado difícil preocuparse por el marcado y preferiría centrarse en el árbol DOM. Por ejemplo, un formulario que tiene filas dinámicas (por ejemplo, "agregar otro archivo adjunto"), es probable que desee el formulario en HTML, el botón "Agregar fila" y el botón Enviar ... probablemente no desee generar el HTML con su lenguaje del lado del servidor o algo así.

Otra regla general puede ser la reutilización. Si su solución se puede aplicar a otros problemas en el lado del cliente, encapsúlela en js.

Creamos aplicaciones de una sola página (al igual que Google Mail) y, literalmente, no hay generación de HTML en el lado del servidor en nuestras aplicaciones. En cambio, estamos usando Backbone.js para estructurar nuestro lado del cliente y Manillares para representar nuestro JSON en plantillas que van a la página. Funciona muy bien y estamos llegando al cierre de nuestra primera aplicación que la usa y abordaremos un proyecto aún más grande en el futuro.

Cualquier tipo de cliente pesado en el que el servidor se usa solo para conservar datos y devolver resultados de consultas es un elemento secundario para un momento en el que va a querer que JavaScript genere HTML. Solo asegúrese de usar un buen motor de plantillas para hacerlo limpio y fácil.

Estoy generando código html en jquery porque estoy usando un portlet y después de la ejecución del código jsp, necesito hacer un bucle con código html, que no puedo obtener en un bucle java for con algún código javascript dentro. Entonces estoy renderizando java arraylist en una matriz de javascript y usando las cadenas para generar html.