Ember.js oder Backbone.js für Restful Backend [geschlossen]


98

Ich weiß bereits, dass ember.js im Gegensatz zu backbone.js ein schwererer Ansatz ist. Ich habe viele Artikel über beide gelesen.

Ich frage mich, welches Framework als Frontend für ein Rails Rest Backend einfacher funktioniert. Für backbone.js habe ich verschiedene Ansätze gesehen, um ein Rest-Backend aufzurufen. Für Glut scheint es, dass ich einige weitere Bibliotheken wie 'Daten' oder 'Ressourcen' hinzufügen muss. Warum gibt es dafür zwei Bibliotheken?

Was ist die bessere Wahl? Es gibt nicht viele Beispiele, um das Frontend mit dem Backend zu verbinden. Was ist ein gutes Beispiel für einen Backend-Rest-Aufruf?

URI: ../restapi/topics Anmeldeinformationen für GET-Authentifizierung: admin / secrect format: json


3
Ich muss eine Frage lieben, die "nicht konstruktiv" ist, aber die hilfreiche, gut durchdachte Antwort hat immer noch mehr als 240 positive Stimmen.
Andrew

Antworten:


257

Entgegen der landläufigen Meinung ist Ember.js kein "schwererer Ansatz" für Backbone.js. Es handelt sich um verschiedene Arten von Werkzeugen, die auf völlig unterschiedliche Endprodukte abzielen. Embers Sweet Spot sind Anwendungen, bei denen der Benutzer die Anwendung für lange Zeiträume, möglicherweise den ganzen Tag, offen hält und Interaktionen mit den Ansichten der Anwendung oder den zugrunde liegenden Daten tiefgreifende Änderungen in der Ansichtshierarchie auslösen. Ember ist größer als Backbone, aber dank Expiresist Cache-Controldies nur bei der ersten Ladung von Bedeutung. Nach zwei Tagen täglicher Nutzung werden diese zusätzlichen 30.000 durch Datenübertragungen überschattet, früher, wenn Ihre Inhalte Bilder enthalten.

Das Backbone ist ideal für Anwendungen mit einer kleinen Anzahl von Zuständen, bei denen die Ansichtshierarchie relativ flach bleibt und der Benutzer dazu neigt, selten oder für kürzere Zeiträume auf die App zuzugreifen. Der Code von Backbone bleibt kurz und bündig, da davon ausgegangen wird, dass die Daten, die das DOM sichern, weggeworfen werden und beide Elemente im Speicher gesammelt werden: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Die kleinere Größe des Backbones eignet sich auch besser für kurze Interaktionen.

Die Apps, die in beiden Frameworks geschrieben werden, spiegeln diese Verwendungszwecke wider: Zu den Apps von Ember.j gehören das Web-Dashboard von Square , Zendesk (zumindest die Agenten- / Ticketing-Oberfläche) und der Scheduler von Groupon : Alle Anwendungen, in denen ein Benutzer möglicherweise den ganzen Tag arbeitet.

Backbone-Apps konzentrieren sich eher auf kurze oder gelegentliche Interaktionen, die oft nur kleine Abschnitte einer größeren statischen Seite sind: Airbnb , Khan Academy , Foursquares Karte und Listen .

Sie können Backbone verwenden, um die Arten von Anwendungen zu erstellen, auf die Ember abzielt (z. B. Rdio ), indem Sie a) die Menge des Anwendungscodes erhöhen, für den Sie verantwortlich sind, um Probleme wie Speicherlecks oder Zombie-Ereignisse zu vermeiden (ich persönlich empfehle diesen Ansatz nicht). oder b) durch Hinzufügen von Bibliotheken von Drittanbietern wie backbone.marionette oder Coccyx - es gibt viele dieser Bibliotheken, die alle versuchen, ähnliche überlappende Funktionen bereitzustellen, und Sie werden wahrscheinlich Ihr eigenes benutzerdefiniertes Framework zusammenstellen, das größer ist und mehr Klebercode erfordert als wenn du nur Ember benutzt hättest.

Letztendlich hat die Frage "was zu verwenden ist" zwei Antworten.

Erstens: "Was sollte ich im Allgemeinen in meiner Karriere verwenden?": Beides, genau wie Sie am Ende alle Tools erlernen werden, die für die Arbeit spezifisch sind, die Sie in Zukunft ausführen möchten. Sie würden nie "Backbone oder D3?" Fragen; "Backbone or Ember" ist eine ebenso dumme Frage.

Zweitens: "Was soll ich speziell für mein nächstes Projekt verwenden?": Hängt vom Projekt ab. Beide kommunizieren gleichermaßen problemlos mit einem Rails-Server. Wenn Ihr nächstes Projekt eine Mischung aus vom Server generierten Seiten mit sogenannten "Inseln des Reichtums" umfasst, die von JavaScript bereitgestellt werden, verwenden Sie Backbone. Wenn Ihr nächstes Projekt die gesamte Interaktion in die Browserumgebung überträgt, verwenden Sie Ember.


4
Tolle Resonanz, Trek. Ich wollte das hier nur kommentieren Expiresund Cache-Controlweit weniger helfen, als die Leute denken - insbesondere in Bezug auf mobile Geräte, die sie oft ignorieren. Ich erinnere mich, dass eine Version von iOS sie vollständig ignoriert hat (aber immer noch das HTML5-Cache-Manifest hört). Darüber hinaus helfen diese Header-Werte beim ersten Besuch eines Benutzers nicht weiter. Dies ist im Allgemeinen am kritischsten bei der Entscheidung, ob der Benutzer bleiben und Ihre App verwenden wird. Den ganzen 30-KB-Dateiunterschied zu sagen, scheint mir keine große Sache zu sein. Ist das roh oder ein minimierter und gezippter Unterschied von 30.000?
Mauvis Ledford

11
Wenn Sie sich die tatsächlichen Anwendungen ansehen, die den Stil haben, den Ember erstellen soll, werden Sie feststellen, dass diese lästigen KBS nicht zu übersehen sind. Entweder stammen sie von Ember und Ihr Anwendungscode ist kleiner, oder sie stammen von Backbone-Plugins, oder sie stammen von Code, den Sie selbst geschrieben haben. Wunderlist , von der Sie denken würden, dass sie "einfache" Uhren mit einer Übertragungsrate von etwa 300 KB sind. Ich würde mir vorstellen, dass es mit Ember ähnlich groß sein würde, vielleicht kleiner - da ich noch nie eine exakte Wunderlist geschrieben habe, kann ich das nicht mit 100% iger Sicherheit sagen.
Trek Glowacki

1
Ich bin damit einverstanden, dass meine beliebteste Backbone-App mit 178 KB + Vorlagen komprimiert und minimiert wird. Ich möchte nur darauf hinweisen, dass wir uns nicht auf das Zwischenspeichern von Browsern verlassen sollten.
Mauvis Ledford

2
Trek, Sie sind genau richtig mit Ihrer Analyse der Verwendung von Backbone in Apps mit erweiterten Nutzungsmustern und komplexer Statusverwaltung. Ich habe die Erfahrung gemacht, eine Legacy-App auf Backbone umzustellen, und musste genau das tun, was Sie aufgelistet haben. Wir mussten Marionette integrieren und viel Klebercode für Dinge wie Filterung vor / nach der Route, Reduzierung von Speicherlecks und besseres Ereignismanagement schreiben.
Mike Clymer

9
"Sie würden niemals Backbone oder D3 fragen" - sicher, aber ich kann mir leicht ein Projekt vorstellen, bei dem ich D3 in Verbindung mit Backbone verwenden würde. Es ist wahrscheinlich viel schwieriger, sich ein Projekt vorzustellen, bei dem Backbone und Ember zusammen auf einer einzigen Seite verwendet werden. Daher finde ich die Frage "Backbone or Ember" ziemlich fair. Hier ist ein weiterer Beitrag, den ich sehr informativ fand, weil er die beiden Frameworks genauer vergleicht: net.tutsplus.com/tutorials/javascript-ajax/…
Shiprack

26

Um eine kurze, vereinfachte Antwort zu geben: Für ein RESTful-Backend sollten Sie derzeit Backbone verwenden.

Um eine komplexere Antwort zu geben: Es hängt wirklich davon ab, was Sie tun. Wie andere gesagt haben, ist Ember für verschiedene Dinge konzipiert und wird eine andere Gruppe von Menschen ansprechen. Meine kurze Antwort basiert auf Ihrer Einbeziehung der RESTful-Anforderung.

Derzeit ist Ember-Data (der Standard-Persistenzmechanismus in Ember) noch lange nicht produktionsbereit. Dies bedeutet, dass es einige Fehler gibt und verschachtelte URIs (z. B. / posts / 2 / comments / 4556) nicht unterstützt. Wenn REST Ihre Anforderung ist, müssen Sie dies vorerst umgehen, wenn Sie sich für Ember entscheiden (dh Sie müssen es entweder hacken, warten, etwas wie Ember-Data von Grund auf selbst implementieren oder nicht verwenden -sehr-RESTful URIs). Ember-Data ist nicht ausschließlich Teil von Ember, daher ist dies durchaus möglich.

Die Hauptunterschiede zwischen den beiden sind neben der Größe im Wesentlichen:

Ember versucht so viel wie möglich für Sie zu tun, damit Sie nicht so viel Code schreiben müssen. Es ist sehr hierarchisch und wenn Ihre App auch sehr hierarchisch ist, wird es wahrscheinlich gut passen. Weil es so viel für Sie tut, kann es schwierig sein, herauszufinden, woher die Fehler kommen, und zu erklären, warum unerwartetes Verhalten auftritt (es gibt viel "Magie"). Wenn Sie eine App haben, die natürlich zu dem App-Typ passt, den Ember von Ihnen erwartet, ist dies wahrscheinlich kein Problem.

Backbone versucht, so wenig wie möglich für Sie zu tun, damit Sie überlegen können, was gerade passiert, und eine Architektur erstellen können, die zu Ihrer App passt (anstatt eine App zu erstellen, die zur Architektur des von Ihnen verwendeten Frameworks passt). Es ist viel einfacher, damit zu beginnen, aber wenn Sie nicht vorsichtig sind, kann es sehr schnell zu einem Durcheinander kommen. Es werden keine Dinge wie berechnete Eigenschaften, Ereignisse zum automatischen Aufheben der Bindung usw. ausgeführt und es bleibt Ihnen überlassen, sodass Sie eine Menge Dinge selbst implementieren müssen (oder zumindest Bibliotheken auswählen müssen, die dies für Sie tun), obwohl dies der Fall ist eher der ganze Punkt.

Update : Es scheint, dass Ember seit kurzem verschachtelte URIs unterstützt. Ich nehme an, die Frage hängt davon ab, wie viel Magie Sie mögen und ob Ember architektonisch gut zu Ihrer App passt.


5
"Entscheidend ist, dass verschachtelte URIs (z. B. / posts / 2 / comments / 4556) nicht unterstützt werden." Hier ist das relevante Commit von vor ein paar Wochen: github.com/emberjs/data/commit/… . Es ist bekannt, dass es schwierig sein kann, mit einem sich schnell bewegenden Pre-Release-Framework Schritt zu halten, aber wir sollten immer auf Genauigkeit achten, wenn wir mit Autorität sprechen und Ratschläge geben!
Trek Glowacki

Cool, danke. Meine Antwort wurde aktualisiert. Ich nehme an, dass dies in der großen Beziehungszusammenführung letzte Woche oder so eingeführt wurde. Ich habe die aufgelisteten Änderungen durchgesehen und gelesen, konnte jedoch keine Erwähnung von URLs finden, und die Probleme, die ich verfolgte, waren noch offen, als ich sie überprüfte. Vielen Dank für den Hinweis auf das Commit - es kann schwierig sein, es zu finden, ohne seine Existenz bereits zu kennen.
Bengillies

Es ist in der Tat aus der jüngsten Fusion der Branche für Beziehungsverbesserungen. Wir haben alte Probleme langsam weiterverfolgt und diese Woche geschlossen.
Trek Glowacki

3

Ich denke, dass Ihre Frage bald blockiert wird :) Es gibt einige Streitigkeiten zwischen den beiden Frameworks.

Grundsätzlich macht Backbone nicht viele Dinge, und deshalb liebe ich es: Sie müssen viel codieren, aber Sie werden am richtigen Ort codieren. Ember macht viele Dinge, also sollten Sie besser aufpassen, was es tut.

Die Serverdiskussion ist eines der wenigen Dinge, die Backbone tut, und es macht einen großartigen Job damit. Also würde ich mit Backbone beginnen und dann Ember ausprobieren, wenn Sie nicht ganz zufrieden sind.

Sie können sich auch diesen Podcast anhören, in dem Jeremy Ashkenas, der Erfinder von Backbone, und Yehuda Katz, Mitglied von Ember, eine nette Diskussion führen


2
Danke dir. Was können Sie über die Rets-Erweiterungen von Ember sagen? Daten oder Ressourcen besser nutzen? Können Sie ein einfaches Beispiel für einen Rest-API-Aufruf geben?
Robin Wieruch

1
Die kurze Antwort lautet, dass die Bibliotheken ständig variieren und ich Ihnen aufgrund meiner bisherigen Erfahrungen keine Antwort geben kann (ich habe sie zur Bewertung selbst vorgenommen). Ich denke, dieser Beitrag wird Ihnen mehr sagen, als ich kann: stackoverflow.com/questions/8623091/ember-js-rest-api
Nicolas Zozol

1
Ich habe diesen Beitrag bereits gesehen. Deshalb habe ich gefragt :)
Robin Wieruch

2
@NicolasZozol welcher Podcast? Verknüpfung ?
Deepak

3
javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas von Anfang Februar. Dies ist, bevor klarer wird, dass diese Frameworks in überlappenden Arenen nicht wirklich existierten. Sie können hören, wie Yehuda und Jeremy nur aneinander vorbeigehen und keine Vergleiche anstellen.
Trek Glowacki
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.