2010-11-19 14 views
13

Estoy construyendo una aplicación web de Django que tiene un montón de html generado sobre la marcha por solicitudes ajax. En este momento, utilizo el lenguaje de plantillas de Django para crear html y luego paso este nuevo HTML como una cadena en el objeto JSON que luego se inyecta en la página con jQuery.Templating con Javascript o Django?

Esto funciona bastante bien, pero con Javascript es tan rápido en los navegadores modernos y con tantas bibliotecas de plantillas de JavaScript creadas, me pregunto si debería empujar todo al lado del cliente.

Así que mi pregunta es: Dada la que mi promedio "página" con todas las peticiones desde y hacia el que tiene que reunir alrededor de ~ 300 plantillas (cada uno de aproximadamente 15 o más líneas con 5 o menos sustituciones) hacia fuera en HTML durante su de por vida, ¿existe una ventaja significativa en el rendimiento al hacer plantillas en el navegador?

Además, ¿alguien puede recomendar una biblioteca de plantillas "rápidas" de Javascript? He oído cosas buenas sobre underscore.js, bigote.js y jQuery template.

+0

las plantillas de cierre son rápidas, porque son compilables por el compilador de google – Evgeny

+0

También he tenido este problema, pero devolver el HTML no es razonable debido a la cantidad de datos involucrados (es para una galería de imágenes con muchas entradas). Lo resolví con el bigote del lado del cliente y del servidor, me gusta el bigote. –

Respuesta

4

La ventaja (masiva) de seguir con las plantillas de Django es que solo necesita utilizar un lenguaje de plantillas, que conserva las mismas capacidades independientemente de la página que desea generar. Si nota que tiene problemas de rendimiento, debería considerar buscar en caching template fragments.

+0

s/Django/Jinja2/g lo hace aún más masivo;) – Evgeny

+0

Por supuesto, si tiene cuidado con las citas, no hay nada que diga que sus plantillas de Django no pueden generar JSON ... con HTML incorporado ... –

0

¿Por qué pasa el HTML como JSON? Simplemente devuelva el HTML y use la función $.html() de jQuery para ponerlo en el <div> o lo que sea.

En cuanto a la plantilla en Javascript, hay Pure. Si está utilizando jQuery (lo recomendaría), it already has a template engine.

+0

Mi los objetos de respuesta contienen otra información (sobre dónde adjuntar el elemento en el dom y los uids), utilizo la función $ .html pero solo le doy la clave del diccionario JSON que contiene el nuevo html. –

0

Puede ser posible hacer plantillas de doble finalidad: para que puedan ser convertidas en marcadores de posición para el reemplazo por js y al mismo tiempo se podrían representar normalmente para la salida del servidor. Solo unas pocas plantillas tendrán que ser de doble propósito como ese: los fragmentos que serán reemplazados por el js.

Estoy de acuerdo con Ignacio, es mucho mejor guardar solo una copia de cada plantilla, para que no tenga que escribir una por separado para el javascript, sin embargo, definitivamente hay margen de mejora desde el enfoque que yo ya he mencionado anteriormente

Idealmente, es posible que desee tener plantillas compiladas en un código de función javascript robusto, así como una cadena simple para la salida del servidor.

Closure templates llamado Soy, resuelven el problema muy bien pero no funcionan (quizás todavía) con Python, pero sí funcionan con Java y Javascript. Esperemos que algún día haya soporte de Python para eso.

Pero incluso si eso sucede, el lenguaje de plantillas probablemente será más restringido, ya que será difícil hacer que cosas como .get_absolute_url(), filtros, etc. funcionen tanto en python como en javascript, todo automáticamente.

3

No creo que una arquitectura de plantillas de servidor y cliente híbrido sea mala. Siempre que codifique una plantilla solo en uno de los entornos.

Cada vez que genera un lado del servidor de páginas, se consume una cantidad de tiempo de proceso y un cierto ancho de banda de red. Esto es lo que paga si usa servidores alojados.
Mientras el navegador del usuario está esperando inactivo en una computadora generalmente inactiva para la respuesta.

Si envía la plantilla en el cliente (HTML + JS), pueden almacenarse en caché, para la sesión o incluso días, si el usuario no los elimina.
Esto reduce el tráfico de red para entregar el mismo contenido varias veces. Como los datos son generalmente más pequeños que su HTML representado equivalente.

Como señala, los motores Javascript de hoy son muy rápidos, así como la computadora que lo ejecutan. Cada vez que envía el trabajo de renderizado al cliente, ahorra tiempo de procesamiento para su servidor y entrega los datos más rápidamente.

Estamos en el otro extremo, ya que corremos todos en el cliente y es por eso que creamos PURE para una representación de cliente ultrarrápida. Nuestra aplicación se ve muy rápido como resultado de esta descentralización.

+0

Gracias por el consejo, revisaré PURE. –

Cuestiones relacionadas