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


98

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


3
Me encanta una pregunta que "no es constructiva", pero la respuesta útil y bien pensada obtuvo más de 240 votos a favor.
Andrew

Respuestas:


257

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.


4
Gran respuesta, Trek. Solo quería comentar aquí eso Expiresy Cache-Controlayudar mucho menos de lo que la gente piensa, especialmente en términos de dispositivos móviles que a menudo los ignoran. Recuerdo que una versión de iOS los ignoró por completo (pero aún escucho el manifiesto de caché HTML5). Además, estos valores de encabezado no ayudarán durante la primera visita de un usuario, que generalmente es lo más importante para decidir si el usuario se quedará y usará su aplicación. Decir toda esa diferencia de archivo de 30kb no me parece tan importante. ¿Eso es crudo o una diferencia de 30k minificada y con gzip?
Mauvis Ledford

11
Si observa aplicaciones reales que tienen el estilo que Ember pretende ayudar a crear, encontrará que no hay escapatoria a esos molestos kbs. O provienen de Ember y el código de su aplicación es más pequeño, o provienen de complementos de la red troncal, o provienen del código que usted mismo escribe. Wunderlist , que usted pensaría que sería "simple", registra alrededor de 300 kb de transferencia. Me imagino que tendría un tamaño similar con Ember, tal vez más pequeño; nunca habiendo escrito una copia exacta de Wunderlist, no puedo decir con 100% de certeza.
Trek Glowacki

1
Estoy de acuerdo, mi aplicación troncal más popular tiene 178kb + plantillas comprimidas y minimizadas. Solo señalando cómo no debemos confiar en el almacenamiento en caché del navegador.
Mauvis Ledford

2
Trek, acertó con su análisis del uso de Backbone en aplicaciones con patrones de uso extendidos y administración de estado compleja. Pasé por la experiencia de convertir una aplicación heredada en Backbone y tuve que hacer exactamente lo que enumeraste. Necesitábamos integrar Marionette, así como escribir mucho código de cola para cosas como el filtrado de ruta antes y después, la mitigación de fugas de memoria y una mejor gestión de eventos.
Mike Clymer

9
"Nunca preguntarías a Backbone o D3", claro, pero puedo imaginar fácilmente un proyecto en el que usaría D3 junto con Backbone. Probablemente sea mucho más difícil imaginar un proyecto en el que Backbone y Ember se usen juntos en una sola página. Entonces, encuentro la pregunta "Backbone o Ember" bastante justa. Aquí hay otra publicación que encontré bastante informativa, porque compara los dos marcos más profundamente: net.tutsplus.com/tutorials/javascript-ajax/…
Shiprack

26

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.


5
"crucialmente, no admite URI anidados (/ posts / 2 / comments / 4556 por ejemplo)" Aquí está la confirmación relevante de hace un par de semanas: github.com/emberjs/data/commit/… . Sabe que puede ser difícil mantenerse al día con un marco previo al lanzamiento que se mueve rápidamente, pero siempre debemos apuntar a la precisión cuando hablamos con autoridad y ofrecemos consejos.
Trek Glowacki

Genial, gracias. Actualicé mi respuesta. Supongo que se introdujo en la gran fusión de relaciones la semana pasada más o menos. Eché un vistazo y leí los cambios enumerados, pero no pude encontrar ninguna mención de las URL y los problemas que estaba rastreando aún estaban abiertos cuando los revisé. Gracias por señalar el compromiso; puede ser difícil de localizar sin saber ya su existencia.
bengillies

De hecho, es de la reciente fusión de la rama de mejora de relaciones. Hemos estado haciendo un seguimiento lento de los problemas antiguos y cerrándolos esta semana.
Trek Glowacki

3

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.


2
Gracias. ¿Qué puedes decir sobre las extensiones rets de ember? ¿Utilizar mejor los datos o los recursos? ¿Puede dar un ejemplo simple de una llamada a la API de rest?
Robin Wieruch

1
La respuesta corta es que las bibliotecas varían todo el tiempo y no puedo darle una respuesta basada en mi experiencia anterior (lo hice por mí mismo para evaluarlo). Creo que esta publicación les dirá más de lo que puedo: stackoverflow.com/questions/8623091/ember-js-rest-api
Nicolas Zozol

1
Ya vi esta publicación. Por eso pregunté :)
Robin Wieruch

2
@NicolasZozol ¿qué podcast? enlace ?
deepak

3
javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas de febrero. Esto es antes de que quede más claro que estos marcos realmente no existían en arenas superpuestas. Puedes escuchar a Yehuda y Jeremy simplemente hablando entre ellos, sin hacer realmente ninguna comparación.
Trek Glowacki
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.