Ember.js o Backbone.js para el backend Restful [cerrado]

Ya sé que ember.js es un enfoque más pesado en contraste con backbone.js. Leí muchos artículos sobre ambos.

Me pregunto qué marco funciona más fácilmente como frontend para un backend de descanso de rieles. Para backbone.js, vi diferentes enfoques para llamar a un backend de descanso. Para ember parece que tengo que incluir algunas bibliotecas más como 'datos' o 'recursos'. ¿Por qué hay dos bibliotecas para esto?

Entonces, ¿cuál es la mejor opción? No hay muchos ejemplos para conectar el frontend con el backend también. Cuál es un buen ejemplo de trabajo para una llamada de descanso de backend a esto:

URI: ../restapi/topics OBTENER credenciales de autenticación: formato admin / secrect: json

Contrariamente a la opinión popular, Ember.js no es un "enfoque más pesado" para Backbone.js. Son diferentes tipos de herramientas que tienen como objetivo productos finales totalmente diferentes. El punto óptimo de Ember son las aplicaciones en las que el usuario mantendrá la aplicación abierta durante largos períodos de tiempo, tal vez todo el día, y las interacciones con las vistas de la aplicación o los datos subyacentes desencadenan cambios profundos en la jerarquía de vistas. Ember es mayor que la espina dorsal, pero gracias a Expires, Cache-Controlesto sólo importa en la primera carga. Después de dos días de uso diario, esos 30k adicionales se verán eclipsados ​​por las transferencias de datos, antes si su contenido incluye imágenes.

Backbone es ideal para aplicaciones con una pequeña cantidad de estados donde la jerarquía de vista permanece relativamente plana y donde el usuario tiende a acceder a la aplicación con poca frecuencia o por períodos de tiempo más cortos. El código de Backbone sigue siendo breve y sencillo porque supone que los datos que respaldan el DOM se desecharán y que ambos elementos se recopilarán en la memoria: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 El tamaño más pequeño de Backbone también lo hace más adecuado para interacciones breves.

Las aplicaciones que la gente escribe en ambos marcos reflejan estos usos: las aplicaciones de Ember.js incluyen el panel web de Square , Zendesk (al menos la interfaz de agente / emisión de tickets) y el programador de Groupon : todas las aplicaciones en las que un usuario puede pasar todo el día trabajando.

Las aplicaciones troncales se centran más en interacciones breves o casuales, que a menudo son solo pequeñas secciones de una página estática más grande: airbnb , Khan Academy , mapas y listas de Foursquare .

Usted puede utilizar Backbone a hacer el tipo de aplicaciones que los objetivos Ember (por ejemplo, Rdio ) por a) el aumento de la cantidad de código de aplicación que es responsable de los problemas a evitar como pérdidas de memoria o eventos zombi (No recomiendo personalmente este enfoque) o b) agregando bibliotecas de terceros como backbone.marionette o Coccyx : hay muchas de estas bibliotecas que intentan proporcionar una funcionalidad superpuesta similar y probablemente terminará ensamblando su propio marco personalizado que es más grande y requiere más código de pegamento que si hubieras usado Ember.

En última instancia, la pregunta de "cuál usar" tiene dos respuestas.

Primero, "¿Cuál debería usar, generalmente, en mi carrera?": Ambos, al igual que terminarás aprendiendo cualquier herramienta específica para el trabajo que quieras hacer en el futuro. Nunca preguntarías "¿Backbone o D3?"; "Backbone or Ember" es una pregunta igualmente tonta.

En segundo lugar, "¿Cuál debería usar, específicamente, en mi próximo proyecto?": Depende del proyecto. Ambos se comunicarán con un servidor Rails con la misma facilidad. Si su próximo proyecto implica una combinación de páginas generadas por el servidor con las llamadas "islas de riqueza" proporcionadas por JavaScript, utilice Backbone. Si su próximo proyecto impulsa toda la interacción al entorno del navegador, use Ember.

Para dar una respuesta breve y simplificada: para un backend RESTful, en este momento, debe usar Backbone.

Para dar una respuesta más compleja: realmente depende de lo que esté haciendo. Como han dicho otros, Ember está diseñado para diferentes cosas y atraerá a un grupo diferente de personas. Mi respuesta corta se basa en su inclusión del requisito RESTful.

Por el momento, Ember-Data (que parece ser el mecanismo de persistencia predeterminado dentro de Ember) está lejos de estar listo para producción. Lo que esto significa es que tiene bastantes errores y, lo que es más importante, no admite URI anidados (/ posts / 2 / comments / 4556 por ejemplo). Si REST es su requisito, entonces tendrá que solucionar esto por el momento si elige Ember (es decir, tendrá que hackearlo, esperar, implementar algo como Ember-Data desde cero usted mismo o no usar -URI muy RESTful). Ember-Data no es estrictamente parte de Ember, por lo que esto es completamente posible.

Las principales diferencias entre los dos, además del tamaño, son básicamente:

Ember intenta hacer todo lo posible por usted, para que no tenga que escribir tanto código. Es muy jerárquico y, si su aplicación también es muy jerárquica, probablemente será una buena opción. Debido a que hace tanto por usted, puede ser difícil averiguar de dónde vienen los errores y razonar por qué ocurre un comportamiento inesperado (hay mucha "magia"). Sin embargo, si tiene una aplicación que encaja naturalmente en el tipo de aplicación que Ember espera que cree, es probable que esto no sea un problema.

Backbone intenta hacer lo menos posible por usted para que pueda razonar sobre lo que está sucediendo y crear una arquitectura que se adapte a su aplicación (en lugar de crear una aplicación que se adapte a la arquitectura del marco que está utilizando). Es mucho más fácil comenzar, pero, a menos que tenga cuidado, puede terminar con un desastre muy rápidamente. No hace cosas como propiedades calculadas, eventos de desvinculación automática, etc. y los deja en sus manos, por lo que deberá implementar muchas cosas usted mismo (o al menos elegir bibliotecas que lo hagan por usted), aunque eso es más bien todo el punto.

Actualización : Parece que, recientemente, Ember ahora admite URI anidados, así que supongo que la pregunta se reduce a cuánta magia le gusta y si Ember es una buena opción, arquitectónicamente, para su aplicación.

Creo que su pregunta pronto será bloqueada :) Hay algunas disputas entre los dos marcos.

Básicamente, Backbone no hace muchas cosas, y por eso me encanta: tendrás que codificar mucho, pero codificarás en el lugar correcto. Ember hace muchas cosas, así que será mejor que mires lo que hace.

La discusión del servidor es una de las pocas cosas que hace Backbone y hace un gran trabajo con ella. Entonces, comenzaría con Backbone y luego probaría Ember si no está totalmente satisfecho.

También puedes escuchar este podcast donde Jeremy Ashkenas, creador de Backbone, y Yehuda Katz, miembro de Ember, tienen una agradable discusión.