18 votos

Por qué no me acaba de construir el conjunto de la aplicación web en Javascript Javascript y HTML Plantillas?

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

  1. En algunas partes de la aplicación, me hacen a las filas de la tabla (jqGrid, slickgrid, etc.) o de lujo div filas (como en el Nuevo Twitter) por el acaparamiento de puro JSON y se ejecuta a través de algo como Bigote, jquery.tmpl, etc.
  2. En otras partes de la aplicación, que acaba de procesar la información en HTML puro (del lado del servidor HAML plantillas), y si no hay búsqueda/paginación, acabo de ir a una nueva URL y cargar una nueva página HTML.

Ahora el problema está en la caché y la facilidad de mantenimiento.

Por un lado estoy pensando, si todo ha sido construido utilizando Javascript, HTML, Plantillas, entonces mi aplicación serviría sólo un diseño HTML/shell, y un montón de JSON. Si usted mira en el Facebook y Twitter de código HTML, que es básicamente lo que están haciendo (95% json/javascript, 5% html). De este modo, sería por lo que mi aplicación solo es necesario caché JSON (páginas, acciones, y/o registros). Lo que significa que hay que pulsar la caché no importa si fueron algunos remoto desarrollador de la api de acceso a una api JSON, o el estrecho web app. Es decir, no necesito 2 cachés, uno para el JSON, uno para el código HTML. Que parece que había cortado mi memoria caché de la tienda de abajo de la mitad, y agilizar un poco las cosas.

Por otro lado, estoy pensando, por lo que he visto/experiencia, la generación de HTML estático en el lado del servidor, almacenamiento en caché y que, parece ser mucho mejor rendimiento sabio cross-browser, se puede obtener la gráfica al instante y no tener que esperar a que una fracción de segundo para javascript para hacerlo. StackOverflow parece hacer todo lo que en formato HTML, por lo que hace Google, y te puedo decir... todo lo que aparece a la vez. Observe cómo a pesar de que en twitter.comla página está en blanco para .5-1 segundos, y la página en trozos en: javascript para representar el json. El inconveniente con esto es que, para cualquier cosa dinámico (como un sinfín de desplazamiento, o rejillas), tendría que crear plantillas javascript de todos modos... así que ahora tengo en el lado del servidor HAML plantillas javascript del lado cliente plantillas y mucho más caché.

Mi pregunta es, ¿hay algún consenso sobre cómo abordar esto? ¿Cuáles son los beneficios y los inconvenientes de su experiencia de la mezcla de los dos frente a acudir al 100% con uno sobre el otro?

Actualización:

Algunas razones por las que el factor de por qué todavía no he tomado la decisión de ir con el 100% de javascript plantillas son:

  • Rendimiento. No he probado formalmente, pero por lo que he visto, raw html que se muestra más rápido y de forma más fluida de javascript-html generado cross-browser. Además, no estoy seguro de cómo los dispositivos móviles manejar html dinámico en cuanto al rendimiento.
  • Pruebas. Tengo un montón de pruebas de integración que funcionan bien con HTML estático, por lo que el cambio a javascript-sólo requeriría 1) centra más puro javascript pruebas (jazmín), y 2) la integración de javascript en capybara pruebas de integración. Esto es sólo una cuestión de tiempo y trabajo, pero es probablemente significativo.
  • Mantenimiento. Deshacerse de HAML. Me encanta HAML, es tan fácil escribir, imprime muy HTML..., código limpio, hace que el mantenimiento sea fácil. Va con javascript, no hay nada tan concisa.
  • SEO. Sé que google controla el ajax /#!/path, pero no he comprendido cómo esto afectará a otros motores de búsqueda y cómo los navegadores más antiguos de manejar. Parece que necesitaría un importante programa de instalación.

8voto

Raynos Puntos 82706

Los compuestos de almacenamiento de datos privados.

Usted necesita un servidor para almacenar datos con distintos niveles de lo público/privado de acceso. También se necesita un servidor para asegurar cerrado fuente de información. Necesita un servidor para hacer el levantamiento de objetos pesados que usted no quiere hacer en el cliente. Complejo de consulta de datos es mejor dejar hasta que su motor de base de datos. La indización y la búsqueda aún no está optimizado para javascript.

También tiene los problemas de los navegadores más antiguos de ser mucho más lento. Si su no ejecución de FF4/Chrome o IE9, a continuación, hay una gran diferencia entre la manipulación de datos y construcción de la página en el cliente y el servidor.

Yo voy a estar tratando de construir una aplicación web realizada totalmente con un marco de MVC y de la plantilla, pero aún con el servidor para la conexión segura y optimizada de la base de datos.

Pero, en general, la aplicación puede ser, de hecho, construir íntegramente en javascript y el uso de plantillas. Las diversas construcciones y motores javascript han avanzado lo suficiente como para hacer esto. Hay bastante popular en los marcos que hay para ello. El javascript Puro aplicaciones web no son experimentos y prototipos.

Ah, y si estaban recomendando marcos para esto, a continuación, echar un vistazo a backbone.js.


Seguridad


No olvidemos que no tenemos confianza en el cliente. Necesitamos serverside de validación. JavaScript es interpretado, dinámico y que puede ser manipulado en tiempo de ejecución. Nosotros nunca la confianza del cliente.

5voto

Daff Puntos 22358

He utilizado para la mezcla de estos dos enfoques, pero luego cambió de lado del cliente de representación del todo porque fue muy duro para soportar un intenso JavaScript correctamente el contrario. Como una solución completa puede recomendar el enfoque de la JavaScriptMVC marco.

Tiene una vista motor de renderizado llamado EJS que puede comprimir sus puntos de vista en la llanura de JavaScript para una producción de compilación de su aplicación. Eso hace que sea muy rápido (todo el código HTML se obtiene precargado con su único comprimido de archivo de JavaScript por lo que se procesa tan pronto como reciba su modelos de datos JSON). Yo personalmente no pude notar una diferencia de rendimiento entre EJS la representación y la transferencia de HTML.

Luego de su API, siguiendo el RESTO de los principios, el almacenamiento en caché es uno de los obstáculos principales. Así que si su aplicación admite el almacenamiento en caché de HTTP correctamente para datos JSON y el uso de la compresión de lado de cliente de plantillas se puede ver una mejora en el rendimiento.

2voto

rhaag71 Puntos 367

Yo podría estar de camino fuera de aquí, pero...

Has mirado en CouchDB? (No tengo ninguna afiliación w/ ellos por CIERTO) yo podría estar mal, pero su situación suena como que podría ser un ajuste perfecto para el uso de la Apache CouchDB realmente no he utilizado todavía mí mismo, pero me tomó un buen vistazo de un corto tiempo atrás y es muy interesante base de datos.

Se trata de un documento basado en la base de datos que utiliza una api REST para las conexiones (muy versátil y fácil de usar). También es muy JSON céntrica, muy rápido y con una pequeña huella; dicen que puede residir en los teléfonos y otros incrustado utiliza demasiado, pero al mismo tiempo se supone que ser extremadamente escalable (hacia arriba). Si su un gran JS usuario (que suena como usted), entonces usted puede estar en casa con ella.

Sólo estaba pensando que podría ser de utilidad en cualquier número de formas que se han propuesto aquí y pensé en meter su cuchara, sólo para darles una idea de las opciones de almacenamiento :)

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: