Ember.js lub Backbone.js for Restful backend [zamknięty]


98

Wiem już, że ember.js jest bardziej ciężkim podejściem w przeciwieństwie do backbone.js. Czytałem wiele artykułów o obu.

Zadaję sobie pytanie, który framework działa łatwiej jako frontend dla backendu Railsów. W przypadku backbone.js widziałem różne podejścia do wywoływania zaplecza resztowego. W przypadku żaru wydaje się, że muszę uwzględnić więcej bibliotek, takich jak „dane” lub „zasoby”. Dlaczego są do tego dwie biblioteki?

Więc jaki jest lepszy wybór? Nie ma też wielu przykładów łączenia frontendu z backendem. Jaki jest dobry przykład roboczy dla wywołania reszty zaplecza:

URI: ../restapi/topics POBIERZ poświadczenia uwierzytelniania: admin / secrect format: json


3
Uwielbiam pytanie, które nie jest „konstruktywne”, ale pomocna, dobrze przemyślana odpowiedź otrzymała ponad 240 głosów za.
Andrew

Odpowiedzi:


257

Wbrew popularnej opinii Ember.js nie jest „bardziej ciężkim podejściem” do Backbone.js. Są to różnego rodzaju narzędzia, których celem są zupełnie inne produkty końcowe. Najlepszym miejscem dla Ember są aplikacje, w których użytkownik utrzymuje aplikację otwartą przez długi czas, być może przez cały dzień, a interakcje z widokami aplikacji lub danymi bazowymi powodują głębokie zmiany w hierarchii widoków. Ember jest większa niż kręgosłup, ale dzięki Expires, Cache-Controlto liczy się tylko na pierwszym obciążeniu. Po dwóch dniach codziennego użytkowania te dodatkowe 30 tys. Zostanie przyćmione przez transfery danych, wcześniej, jeśli Twoje treści obejmują obrazy.

Sieć szkieletowa jest idealna do zastosowań z niewielką liczbą stanów, w których hierarchia widoków pozostaje stosunkowo płaska i gdzie użytkownik ma tendencję do rzadkiego uzyskiwania dostępu do aplikacji lub przez krótsze okresy. Kod Backbone pozostaje krótki i słodki, ponieważ zakłada, że ​​dane stanowiące kopię zapasową DOM zostaną wyrzucone, a oba elementy zostaną zebrane w pamięci: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Mniejszy rozmiar Backbone sprawia, że ​​lepiej nadaje się do krótkich interakcji.

Aplikacje, które ludzie piszą w obu frameworkach, odzwierciedlają te zastosowania: aplikacje Ember.js obejmują pulpit nawigacyjny Square , Zendesk (przynajmniej interfejs agenta / biletowania) i harmonogram Groupon : wszystkie aplikacje, w których użytkownik może pracować przez cały dzień.

Aplikacje Backbone koncentrują się bardziej na krótkich lub nieformalnych interakcjach, które często są tylko małymi sekcjami większej statycznej strony: airbnb , Khan Academy , mapa i listy Foursquare .

Państwo może używać Backbone aby rodzaje aplikacji, które cele Ember (np Rdio ) poprzez: a) zwiększenie ilości kodu aplikacji jesteś odpowiedzialny za problemy Unikaj jak wycieki pamięci lub zdarzeń zombie (Osobiście nie polecam tej metody) lub b) dodając biblioteki zewnętrzne, takie jak backbone.marionette lub Coccyx - jest wiele z tych bibliotek, które wszystkie starają się zapewnić podobną nakładającą się funkcjonalność i prawdopodobnie skończysz na złożeniu własnej niestandardowej struktury, która jest większa i wymaga więcej kodu kleju niż gdybyś właśnie używał Ember.

Ostatecznie pytanie, „którego użyć”, ma dwie odpowiedzi.

Po pierwsze, „Z których ogólnie powinienem korzystać w swojej karierze”: Oba, tak jak w końcu nauczysz się wszelkich narzędzi specyficznych dla pracy, którą będziesz chciał wykonywać w przyszłości. Nigdy nie zapytałeś „Backbone czy D3?”; „Backbone or Ember” to równie głupie pytanie.

Po drugie, „Którego należy użyć w szczególności w moim następnym projekcie”: Zależy od projektu. Oba będą komunikować się z serwerem Rails z równą łatwością. Jeśli Twój następny projekt obejmuje połączenie stron generowanych przez serwer z tak zwanymi „wyspami bogactwa” zapewnianymi przez JavaScript, użyj Backbone. Jeśli twój następny projekt wypycha całą interakcję do środowiska przeglądarki, użyj Ember.


4
Świetna odpowiedź, Trek. Chciałem tylko to skomentować Expiresi Cache-Controlpomóc o wiele mniej, niż myślą ludzie - zwłaszcza w odniesieniu do urządzeń mobilnych, które często je ignorują. Pamiętam, że wersja iOS całkowicie je zignorowała (ale nadal słucha manifestu pamięci podręcznej HTML5). Ponadto te wartości nagłówka nie pomogą podczas pierwszej wizyty użytkownika - co zazwyczaj jest najbardziej krytyczne przy podejmowaniu decyzji, czy użytkownik pozostanie i będzie korzystał z Twojej aplikacji. Mówienie o tej różnicy między plikami o wielkości 30 kb nie wydaje mi się aż tak wielkim problemem. Czy to różnica w postaci surowej czy zminimalizowanej i spakowanej 30k?
Mauvis Ledford

11
Jeśli spojrzysz na rzeczywiste aplikacje, których styl ma pomóc w tworzeniu Ember, przekonasz się, że nie ma ucieczki od tych nieznośnych kbs. Albo pochodzą z Ember, a kod twojej aplikacji jest mniejszy, albo pochodzą z wtyczek szkieletu, albo pochodzą z kodu, który sam napiszesz. Wunderlist , który można by pomyśleć, byłby „prostym” zegarem przy transferze około 300 kb. Wyobrażam sobie, że miałby podobny rozmiar z Ember, być może mniejszy - nigdy nie napisałem dokładnej kopii Wunderlist, której nie mogę powiedzieć ze 100% pewnością.
Trek Glowacki

1
Zgadzam się, moje najpopularniejsze zegary aplikacji szkieletowej mają ponad 178 kb szablonów skompresowanych i zminimalizowanych. Po prostu wskazuję, jak nie powinniśmy polegać na buforowaniu przeglądarki.
Mauvis Ledford

2
Trek, jesteś na miejscu, analizując wykorzystanie Backbone w aplikacjach o rozszerzonych wzorcach użytkowania i złożonym zarządzaniu stanem. Przeszedłem przez proces konwersji starszej aplikacji na Backbone i musiałem zrobić dokładnie to, co wymieniłeś. Musieliśmy zintegrować Marionette, a także napisać mnóstwo kodu klejącego na takie rzeczy, jak filtrowanie tras przed / po, ograniczanie wycieków pamięci i lepsze zarządzanie zdarzeniami.
Mike Clymer,

9
„Nigdy nie zapytałbyś Backbone czy D3” - jasne, ale łatwo mogę sobie wyobrazić projekt, w którym użyłbym D3 w połączeniu z Backbone. Prawdopodobnie znacznie trudniej wyobrazić sobie projekt, w którym Backbone i Ember są używane razem na jednej stronie. Dlatego uważam, że pytanie „Backbone or Ember” jest całkiem sprawiedliwe. Oto kolejny post, który uważam za dość pouczający, ponieważ bardziej szczegółowo porównuje dwa frameworki: net.tutsplus.com/tutorials/javascript-ajax/ ...
Shiprack

26

Aby dać krótką, uproszczoną odpowiedź: w przypadku zaplecza RESTful, w tej chwili powinieneś użyć Backbone.

Aby udzielić bardziej złożonej odpowiedzi: to naprawdę zależy od tego, co robisz. Jak powiedzieli inni, Ember jest przeznaczony do różnych celów i spodoba się innym grupom ludzi. Moja krótka odpowiedź opiera się na włączeniu przez Ciebie wymagania RESTful.

W tej chwili Ember-Data (który wydaje się być domyślnym mechanizmem trwałości w Ember) nie jest jeszcze gotowy do produkcji. Oznacza to, że ma sporo błędów i, co najważniejsze, nie obsługuje zagnieżdżonych identyfikatorów URI (na przykład / posts / 2 / comments / 4556). Jeśli REST jest twoim wymaganiem, na razie będziesz musiał obejść ten problem, jeśli wybierzesz Ember (tj. Będziesz musiał go włamać, poczekać, zaimplementować coś takiego jak Ember-Data od zera lub nie używać -very-RESTful URI). Ember-Data nie jest ściśle częścią Ember, więc jest to całkowicie możliwe.

Główne różnice między nimi, oprócz wielkości, to w zasadzie:

Ember stara się zrobić dla Ciebie jak najwięcej, abyś nie musiał pisać tak dużo kodu. Jest bardzo hierarchiczna i jeśli Twoja aplikacja jest również bardzo hierarchiczna, prawdopodobnie będzie dobrze pasować. Ponieważ robi tak wiele dla Ciebie, może być trudno dowiedzieć się, skąd pochodzą błędy i wyjaśnić, dlaczego dochodzi do nieoczekiwanego zachowania (jest dużo „magii”). Jeśli jednak masz aplikację, która w naturalny sposób pasuje do typu aplikacji, którą zamierza tworzyć Ember, prawdopodobnie nie będzie to problem.

Backbone stara się robić jak najmniej dla Ciebie, abyś mógł zastanowić się nad tym, co się dzieje i zbudować architekturę pasującą do Twojej aplikacji (zamiast budować aplikację, która pasuje do architektury używanego frameworka). O wiele łatwiej jest zacząć, ale jeśli nie jesteś ostrożny, możesz bardzo szybko skończyć z bałaganem. Nie robi rzeczy takich jak obliczone właściwości, automatyczne rozpinanie zdarzeń itp. I pozostawia je tobie, więc będziesz musiał sam zaimplementować wiele rzeczy (lub przynajmniej wybrać biblioteki, które robią to za ciebie), chociaż to jest raczej cały punkt.

Aktualizacja : Wygląda na to, że od niedawna Ember obsługuje teraz zagnieżdżone identyfikatory URI, więc przypuszczam, że pytanie sprowadza się do tego, jak bardzo lubisz magię i czy Ember dobrze pasuje architektonicznie do Twojej aplikacji.


5
„co najważniejsze, nie obsługuje zagnieżdżonych identyfikatorów URI (na przykład / posts / 2 / comments / 4556)” Oto odpowiednie zatwierdzenie sprzed kilku tygodni: github.com/emberjs/data/commit/… . Wie, że może być trudno nadążyć za szybko zmieniającym się frameworkiem przed wydaniem, ale zawsze powinniśmy dążyć do dokładności, gdy rozmawiamy z autorytetami i udzielamy porad!
Trek Glowacki

Fajne dzięki. Zaktualizowałem moją odpowiedź. Przypuszczam, że zostało to wprowadzone w zeszłym tygodniu w wielkim fuzji relacji. Przejrzałem i przeczytałem wymienione zmiany, ale nie znalazłem żadnej wzmianki o adresach URL, a problemy, które śledziłem, były nadal otwarte, gdy je sprawdzałem. Dziękuję za wskazanie zobowiązania - może być trudne do zlokalizowania bez wiedzy o jego istnieniu.
bengillies

Rzeczywiście, pochodzi to z niedawnego połączenia branży poprawy relacji. Powoli śledzimy stare problemy i zamykamy je w tym tygodniu.
Trek Glowacki

3

Myślę, że Twoje pytanie wkrótce zostanie zablokowane :) Pomiędzy tymi dwoma frameworkami jest kilka sporów.

Zasadniczo Backbone nie robi wielu rzeczy i dlatego go uwielbiam: będziesz musiał dużo kodować, ale będziesz kodować we właściwym miejscu. Ember robi wiele rzeczy, więc lepiej uważaj, co robi.

Dyskusja na serwerze jest jedną z niewielu rzeczy, które robi Backbone i robi z nią świetną robotę. Zacząłbym więc od Backbone, a następnie spróbowałbym Ember, jeśli nie jesteś w pełni zadowolony.

Możesz także posłuchać tego podcastu, w którym Jeremy Ashkenas, twórca Backbone, i Yehuda Katz, członek Ember, prowadzą miłą dyskusję


2
Dziękuję Ci. Co możesz powiedzieć o rets rozszerzeniach żaru. Lepiej wykorzystaj dane lub zasoby? Czy możesz podać prosty przykład wywołania restowego interfejsu API?
Robin Wieruch

1
Krótka odpowiedź jest taka, że ​​biblioteki cały czas się zmieniają i nie mogę udzielić odpowiedzi na podstawie moich wcześniejszych doświadczeń (zrobiłem to na sobie do oceny). Myślę, że ten post powie Ci więcej niż ja: stackoverflow.com/questions/8623091/ember-js-rest-api
Nicolas Zozol

1
Widziałem już ten post. Dlatego zapytałem :)
Robin Wieruch

2
@NicolasZozol który podcast? link?
deepak

3
javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas od lutego. To było zanim stało się jasne, że te ramy tak naprawdę nie istniały na nakładających się arenach. Słychać, jak Yehuda i Jeremy rozmawiają obok siebie, nie robiąc żadnych porównań.
Trek Glowacki
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.