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

Question

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

Ya conozco esa brasa.js es un enfoque de peso más pesado en contraste con backbone.js. Leí muchos artículos sobre ambos.

Me pregunto qué framework funciona más fácilmente como frontend para un backend rails rest. Para la columna vertebral.js Vi diferentes enfoques para llamar a un backend de descanso. Para ember parece que tengo que incluir algunas bibliotecas más como 'data'o ' resources'. ¿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 rest de backend a esto:

URI: ../restapi/temas CONSEGUIR credenciales de autenticación: admin / secrect formato: json

97

rest backbone.js ember.js ruby-on-rails frontend

Author: Robin Wieruch, 2012-10-21

Source

3 answers

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

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

Por el momento, Ember-Data (que parece ser el mecanismo de persistencia predeterminado dentro de Ember) está lejos de la producción ¿Listos?. Lo que esto significa es que tiene bastantes errores y, crucialmente, no soporta URI anidados (/posts/2/comments/4556 por ejemplo). Si el DESCANSO es su requisito, entonces usted tendrá que trabajar alrededor de esto por el momento si elige Ember (es decir, usted tendrá que hackearlo, esperar, implementar algo como Ember-Data desde cero usted mismo, o utilizar URI no-muy-RESTful). Ember-Data no es estrictamente parte de Ember, por lo que esto es completamente posible.

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

Ember intenta hacer todo lo posible por ti, para que no tengas que escribir tanto código. Es muy jerárquico y, si tu aplicación también es muy jerárquica, probablemente será una buena opción. Debido a que hace mucho por usted, puede ser difícil averiguar de dónde vienen los errores y razonar por qué está sucediendo un comportamiento inesperado (hay mucha "magia"). Si tienes una aplicación que encaja de forma natural en el tipo de aplicación que Ember espera que seas construir sin embargo, esto probablemente no será un problema.

Backbone intenta hacer lo menos posible por usted para que pueda razonar sobre lo que está pasando y construir una arquitectura que se ajuste a su aplicación (en lugar de construir una aplicación que se ajuste a la arquitectura del marco que está utilizando). Es mucho más fácil de empezar, pero, a menos que tengas cuidado, puedes terminar con un lío muy rápido. No hace cosas como propiedades computadas, eventos de auto-desvinculación, etc. y las deja en tus manos, por lo tanto, tendrá que implementar un montón de cosas usted mismo (o al menos elegir bibliotecas que lo hagan por usted), aunque ese es más bien el punto.

Update: Parece que, desde hace poco, Ember ahora admite URI anidados, así que supongo que la pregunta se reduce a cuánta magia te gusta y si Ember es una buena opción, arquitectónicamente, para tu aplicación.

26

Author: bengillies,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-10-22 22:17:05

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 vigiles lo que está haciendo.

La discusión del servidor es una de las pocas cosas que hace Backbone, y hace un gran trabajo con ella. Así que empezaría con la columna vertebral y luego dar un intento de Brasa si no estás 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

3

Author: Nicolas Zozol,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-04-08 10:16:59

score 258 · Accepted Answer

Contrario a la opinión popular Ember.js no es un "enfoque más pesado" para Backbone.js. Son diferentes tipos de herramientas que apuntan a productos finales totalmente diferentes. El punto dulce de Ember son las aplicaciones donde 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 más grande que Backbone, pero gracias a Expires, Cache-Control esto sólo importa en en el el 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 involucra imágenes.

Backbone es ideal para aplicaciones con un pequeño número de estados donde la jerarquía de vistas permanece relativamente plana y donde el usuario tiende a acceder a la aplicación con poca frecuencia o durante períodos de tiempo más cortos. El código de Backbone se mantiene corto y dulce porque asume que los datos que respaldan el DOM se desecharán y ambos elementos lo harán ser memoria recogida: 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 frameworks reflejan estos usos: Ember.las aplicaciones js incluyen El panel web de Square, Zendesk (al menos la interfaz agente/ticketing), y Groupon's scheduler: todas las aplicaciones en las que un usuario puede pasar todo el día trabajando.

Backbone apps focus 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, Academia Khan, Mapa y listas de Foursquare .

Usted puede usar Backbone para hacer los tipos de aplicaciones que Ember apunta (por ejemplo, Rdio ) por un) aumentar la cantidad de código de aplicación de la que eres responsable para evitar problemas como fugas de memoria o eventos zombie (personalmente no recomiendo este enfoque) o b) agregando 3rd party bibliotecas como backbone.marionette o Coccyx – hay muchas de estas bibliotecas que todas intentan proporcionar una funcionalidad similar superpuesta y probablemente terminarás armando tu 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, "¿Qué debo usar, generalmente, en mi carrera": Ambos, al igual que terminarás aprendiendo cualquier herramienta específica para trabajo que querrás hacer en el futuro. Nunca preguntarías " Backbone o D3?"; "Backbone or Ember" es una pregunta igualmente tonta.

Segundo, "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 mezcla de páginas generadas por el servidor con las llamadas "islas de riqueza" proporcionadas por JavaScript, use Backbone. Si su próximo proyecto empuja toda la interacción en el navegador ambiente, usa Brasa.