¿Por qué no acabo de construir toda la aplicación web en plantillas HTML de Javascript y Javascript?

Question

Estoy llegando al punto en una aplicación donde tengo que empezar las cosas de almacenamiento en caché, y eso me hizo pensar ...

1. En algunas partes de la aplicación, que rinden filas de la tabla (jqGrid, slickgrid, etc.) o filas div sofisticadas (como en el Nuevo Twitter) agarrando JSON puro y ejecutándolo a través de algo como Moustache, jquery.tmpl, etc.
2. En otras partes de la aplicación, simplemente renderizo la información en HTML puro (Plantillas HAML del lado del servidor), y si hay búsqueda/paginación, simplemente voy a una nueva URL y cargo una nueva página HTML.

Ahora el problema está en el almacenamiento en caché y la mantenibilidad.

Por un lado, estoy pensando, si todo se construyera usando Plantillas HTML de JavaScript, entonces mi aplicación solo serviría un diseño/shell HTML, y un montón de JSON. Si miras la fuente HTML de Facebook y Twitter, eso es básicamente lo que están haciendo (95% json/javascript, 5% html). Esto lo haría para que mi aplicación solo necesite almacenar en caché JSON (páginas, acciones y/o registros). Lo que significa que presionarías el caché sin importar si eras un desarrollador de API remota que accedía a una api de JSON o a la aplicación web de estrecho. Es decir, no necesito 2 cachés, uno para JSON y otro para HTML. Parece que eso reduciría mi almacén de caché a la mitad, y racionalizaría las cosas un poco.

Por otro lado, estoy pensando, por lo que he visto/experimentado, generar HTML estático en el servidor, y almacenarlo en caché, parece ser mucho mejor en cuanto a rendimiento, navegador cruzado; obtienes los gráficos instantáneamente y no tienes que esperar esa fracción de segundo para que javascript los renderice. StackOverflow parece hacer todo en HTML simple, también lo hace Google, y se puede decir ... todo aparece a la vez. Observe cómo sin embargo en twitter.com, la página está en blanco durante .5-1 segundos, y la página se divide en pedazos: el javascript tiene que representar el json. La desventaja de esto es que, para cualquier cosa dinámica (como desplazamiento interminable o cuadrículas), tendría que crear plantillas de JavaScript de todos modos ... así que ahora tengo plantillas HAML del lado del servidor, plantillas de JavaScript del lado del cliente, y mucho más a la memoria caché.

Mi pregunta es, ¿hay algún consenso sobre cómo abordar esto? ¿Cuáles son los beneficios y desventajas de su experiencia de mezclar los dos versus ir al 100% con uno sobre el otro?

Actualización:

Algunas de las razones que tener en cuenta en qué todavía no he tomado la decisión de seguir con el 100% javascript plantillas son:

• Rendimiento. No lo he probado formalmente, pero por lo que he visto, el html crudo rinde más rápido y con más fluidez que el html cross-browser generado por javascript. Además, no estoy seguro de cómo los dispositivos móviles manejan el html dinámico en cuanto al rendimiento.
• Prueba. Tengo un montón de pruebas de integración que funcionan bien con HTML estático, por lo que cambiar a javascript solo requeriría 1) prueba de javascript pura más centrada (jasmine), y 2) integración de javascript en las pruebas de integración de capibaras. Esto es solo una cuestión de tiempo y trabajo, pero probablemente sea significativo.
• Mantenimiento. Deshacerse de HAML. Me encanta HAML, es tan fácil de escribir, imprime bonito HTML ... Hace que el código esté limpio, hace que el mantenimiento sea fácil. Yendo con javascript, no hay nada tan conciso.
• SEO.Sé que Google maneja el ajax /#!/path, pero no he entendido cómo afectará esto a otros motores de búsqueda y cómo lo manejan los navegadores más antiguos. Parece que requeriría una configuración significativa.

Answer 1

Almacenamiento de datos privados persistentes.

Necesita un servidor para almacenar datos con varios niveles de acceso público/privado. También necesita un servidor para obtener información segura de código cerrado. Necesita un servidor para hacer trabajos pesados ​​que no desea hacer en el cliente. La consulta de datos complejos se deja hasta su motor de base de datos. La indexación y la búsqueda aún no están optimizadas para javascript.

También tiene problemas con los navegadores más antiguos que son mucho más lentos. Si no está ejecutando FF4/Chrome o IE9, entonces existe una gran diferencia entre la manipulación de datos y la construcción de la página en el cliente y el servidor.

Yo mismo voy a tratar de crear una aplicación web hecha completamente utilizando un marco MVC y plantilla pero aún usando el servidor para conectarme a una base de datos segura y optimizada.

Pero, en general, la aplicación puede construirse completamente en javascript y usar plantillas. Los diversos constructos y motores de JavaScript han avanzado lo suficiente como para hacer esto. Hay suficientes marcos populares para hacer esto. Las aplicaciones web de Pure javascript ya no son experimentos y prototipos.

Ah, y si estaban recomendando marcos para esto, entonces eche un vistazo a backbone.js.

---

Seguridad

---

No olvidemos que no confiamos en el cliente. Necesitamos validación en el servidor. JavaScript es interpretado, dinámico y puede ser manipulado en tiempo de ejecución. Nunca confiamos en la opinión del cliente.

Answer 2

Solía ​​mezclar estos dos enfoques, pero luego pasé a la representación del lado del cliente porque era muy difícil manejar JavaScript pesado de otra manera. Como solución completa puede recomendar el enfoque del marco JavaScriptMVC.

Tiene un motor de representación de vistas llamado EJS que puede comprimir sus vistas en JavaScript plano para una compilación de producción de su aplicación. Eso lo hace extremadamente rápido (todo su HTML se precarga con su único archivo JavaScript comprimido para que se represente tan pronto como reciba los datos JSON de su modelo). Personalmente, no pude notar una diferencia de rendimiento entre la representación de EJS y la transferencia de HTML sin formato.

Luego, para su API, siguiendo los principios de REST, el almacenamiento en caché es una de las principales restricciones. Por lo tanto, si su aplicación admite el almacenamiento en caché de HTTP correctamente para datos JSON y utiliza sus plantillas comprimidas del lado del cliente, es posible que incluso vea una mejora en el rendimiento.

Answer 3

Podría estar muy lejos de aquí, pero ...

¿Alguna vez ha mirado CouchDB? (No tengo ninguna afiliación con ellos por cierto) Podría estar muy equivocado, pero su situación parece que puede ser una opción perfecta para el uso del Apache CouchDB. No lo he usado todavía, pero lo analicé bien. Hace poco tiempo y es una base de datos muy interesante.

Es una base de datos basada en documentos que utiliza una API REST para las conexiones (muy versátil y fácil de usar).También es muy centrado en JSON, muy rápido y una huella pequeña; dicen que también puede residir en teléfonos y otros usos integrados, pero al mismo tiempo se supone que es extremadamente escalable (hacia arriba). Si eres un gran usuario de JS (que pareces ser), entonces puedes estar en casa con él.

Estaba pensando que puede ser útil en cualquier número de formas que se han propuesto aquí y pensé que interrumpiría sólo para darle una idea de las opciones de almacenamiento :)