programar - juegos en javascript codigo fuente

Marcos de JavaScript para construir aplicaciones de una sola página

Question

Mi objetivo es migrar una aplicación web existente a una aplicación RESTful de una sola página (SPA). Actualmente, estoy evaluando varios marcos de aplicaciones web de JavaScript.

Mis requisitos son los siguientes:

• Capa de datos RESTful (como Ember-Data)
• Estructura MV *
• Rutas dinámicas
• Prueba de soporte
• Codificando por convención
• Soporte SEO
• Navegador-Historial-Soporte
• Buena documentación (API)
• Listo para producción
• Comunidad viviente

Backbone

La aplicación actual está utilizando backbone.js . En general, backbone.js es un buen proyecto, pero me faltan estructuras bien definidas que determinen dónde debe suceder lo que debe suceder y cómo deben implementarse las cosas. Trabajar en un equipo más grande con desarrolladores cambiantes esto lleva a algún tipo de código no estructurado, difícil de mantener y difícil de entender. Es por eso que estoy buscando un marco, que ya define todo esto.

Ember

Miré en ember.js los últimos días. El enfoque me parece muy prometedor. Pero, lamentablemente, el código cambia casi a diario. Por lo tanto, no lo llamaré listo para producción. Y, lamentablemente, no podemos esperar a que sea la versión 1.0. Pero realmente me gusta la idea detrás de este marco.

Angular

Angular.js es un framework ampliamente difundido también, mantenido por Google. Pero no me pude familiarizar con angular. Para mí, la estructura parece poco clara, faltan explicaciones sobre las responsabilidades generales de cada parte del marco, y las implementaciones se sienten tortuosas. Solo para aclarar esto: esta es solo mi impresión personal y podría estar basada en el conocimiento perdido.

Batman y Meteor

Como entendí, ambos frameworks también necesitan una parte de servidor. Y dado que solo queremos un back-end RESTful, sin importar el lenguaje, la técnica o el software, esto no es lo que queremos. Además, la API de back-end ya existe (RoR).

Knockout , CanJS y Spine

No profundicé en estos tres candidatos. Quizás este sea mi próximo paso.

Entonces mis preguntas ahora:

• ¿Me estoy perdiendo algún buen marco de SPA?
• ¿Qué marco recomendaría / recomendaría?
• ¿Evitarías alguno de los marcos mencionados?
• ¿Cuál es su experiencia en aplicaciones SP más grandes?

PD: Me gustaría recomendar un gran post de blog de Steven Anderson (desarrollador principal de Knockout.js) sobre la conferencia "Throne of JS" (desde 2012) y marcos de JavaScript en general.

PD: Sí, sé que ya hay alguna pregunta sobre SO. Pero dado que el desarrollo es tan rápido y rápido para las ZPE, la mayoría de ellas ya están desactualizadas.

Answer 1

Ha pasado un año desde que comenzamos el desarrollo de nuestro proyecto de servicios en la nube con numerosas SPA, por lo que fue una gran decisión, qué framework de JavaScript usar para nuestra interfaz de usuario para satisfacer nuestras necesidades de arquitectura RESTful. y después de muchas investigaciones terminamos usando el framework Dojo .

características principales que te encantarán:

1. comunidad educada y un equipo que creó un patrón de diseño perfecto. grandes convenciones y arquitectura modular / orientada a objetos. con las actitudes de programación de CrossBrowser :)
2. Estructura MV * crea widgets UI con plantillas .htm externas y, para producción, compila todas tus javascript y plantillas en un .js único, minificado y pequeño.
3. construir clases con herencia. establecedores de propiedades, muchas herramientas de funciones.
4. mecanismo pub / sub (temas nombrados en dojo)
5. una gran cantidad de controles de interfaz de usuario, desde control de formularios de validación, diálogos / información sobre herramientas hasta una tabla de grúas de datos, altamente personalizables (pero livianas) y con muchas funciones.
6. un buen sistema de prueba unitaria llamado DOH. también tiene un robot para reproducir acciones de mouse / teclado.
7. una herramienta de consulta (como JQuery) llamada NodeList con todas las características jquery e incluso muchos de sus complementos.
8. y la parte buena pero no tan completa. tiene un módulo JsonRest para usar con sus servicios REST. es una herramienta práctica pero carece de muchas funciones.

Para superar estos problemas, desarrollamos una herramienta de sondeo AJAX, manejo de errores y universal, carga y notificaciones. lo hicimos muy fácilmente utilizando las convenciones y estructuras del marco dojo. si no quieres hacer eso, tal vez tengas que usar otro marco para esta parte.

Al observar los excelentes SPA en la web, descubrirá que todos ellos están personalizados y utilizan múltiples marcos. pero nuestra experiencia con Dojo solo fue fantástica. y por lo tanto, le sugiero que no piense en ningún otro marco, ya que todos están incompletos para un SPA. pero al final también tiene otra opción (que no recomiendo y no tengo información detallada). vaya con un marco JAVA que sea capaz de construir SPA, generando automáticamente IU y javascript.

Answer 2

Recientemente también tuve que decidir sobre un marco JavaScript SPA en un proyecto.

• Ember

  Miré a Ember desde el principio y tenía pensamientos similares a los tuyos: realmente me gustó, pero me pareció que todavía era demasiado pronto para usar ... aproximadamente la mitad de los tutoriales que leí no funcionaron con la versión actual porque algo había sucedido recientemente. cambiado en cómo funciona la creación de plantillas.

• Backbone

  El backbone fue el primer framework que consideramos seriamente. No estoy seguro de entender por qué piensas que no tiene "estructuras bien definidas". El backbone es bastante claro sobre cómo dividir el código de modelo y vista. ¿Quizás quieres decir que no hay algún tipo de plantilla de aplicación? De todos modos, Backbone parece realmente enfocado en la parte del modelo / REST-binding, pero realmente no prescribe nada para el enlace de la vista. Si el enlace modelo es importante para ti y estás usando Rails, hacer esto debería ser muy fácil. Desafortunadamente, los servicios web para mi aplicación realmente no coincidían, y tuve que escribir mis propios métodos .sync y .parse para todo. La separación de los códigos Modelo y Vista fue agradable, pero dado que tendríamos que escribir todas nuestras encuadernaciones desde cero, no valía la pena.

• Knockout

  Knockout es como el Yang de Yin to Backbone. Cuando Backbone se centra en el Modelo, Knockout es un marco MVVM y se centra en la Vista. Tiene envoltorios observable para propiedades de objetos de JavaScript y usa un atributo de vinculación de data-bind para vincular propiedades a su HTML. Al final fuimos con Knockout ya que el enlace de vista era principalmente lo que necesitábamos para nuestra aplicación. (... más otros, como veremos más adelante ...) Si te gusta el enlace de vista de Knockout y los enlaces de modelo de Backbone también hay KnockBack que combina ambos frameworks.

• Angular

  Visto esto después de Knockout - lamentablemente todos parecimos bastante felices con la forma en que Knockout vio el enlace. Parecía mucho más complejo y difícil de entrar que Knockout. Y usa un montón de atributos HTML personalizados para hacer enlaces, lo cual no estoy seguro de que me guste ... Puedo mirar más a Angular más tarde, porque dado que me he topado con varias personas a las que realmente les gusta el marco, tal vez Acabo de verlo demasiado tarde para este proyecto.

• Batman , Meteor , CanJS , Spine

  Realmente no miré muy de cerca a ninguno de estos. Aunque sé que Spine es un marco similar a Backbone con explícitos objetos Controller, y está escrito en CoffeeScript.

• Epílogo

  Como mencioné, terminamos usando Knockout porque, para nuestro proyecto, enfocarnos en la vinculación de vistas era más importante. También terminamos utilizando RequireJS para la modularización, RequireJS y Hasher para gestionar el enrutamiento y el historial, Jasmine para pruebas, así como JQuery , Twitter Bootstrap y Underscore.js (y probablemente más bibliotecas que estoy olvidando en este momento).

  El desarrollo de la aplicación JavaScript se parece más al ecosistema de Java que al ecosistema de Rails. Rails proporciona un núcleo sólido de cosas que vas a utilizar para cada aplicación (framework de Rails), y la comunidad proporciona muchas personalizaciones además de eso (gems). Java proporciona ... un lenguaje. Y luego puede elegir Java EE o Spring o Play o Struts o Tapestry. Y elija JDBC o Hibernate o TopLink o Ibatis para hablar con la base de datos. Y luego puedes usar Ant, Maven o Gradle para construirlo. Y elija Tomcat o Jetty o JBoss o WebLogin para ejecutarlo. Por lo tanto, hay más énfasis en elegir lo que necesita y lo que funciona en conjunto que elegir EL marco de trabajo a usar.