Ember.js o Backbone.js per il backend riposante [chiuso]


98

So già che ember.js è un approccio più pesante rispetto a backbone.js. Ho letto molti articoli su entrambi.

Mi chiedo quale framework funzioni più facilmente come frontend per un backend di rails rest. Per backbone.js ho visto diversi approcci per chiamare un backend di riposo. Per ember sembra che debba includere altre librerie come "dati" o "risorse". Perché ci sono due biblioteche per questo?

Allora qual è la scelta migliore? Non ci sono molti esempi per collegare anche il frontend con il backend. Qual è un buon esempio funzionante per una chiamata di riposo back-end a questo:

URI: ../restapi/topics OTTIENI le credenziali di autenticazione: formato admin / secrect: json


3
Devo amare una domanda che "non è costruttiva", ma la risposta utile e ben ponderata ha comunque ricevuto oltre 240 voti positivi.
Andrew

Risposte:


257

Contrariamente all'opinione popolare, Ember.js non è un "approccio più pesante" a Backbone.js. Sono diversi tipi di strumenti destinati a prodotti finali completamente diversi. Il punto debole di Ember sono le applicazioni in cui l'utente manterrà l'applicazione aperta per lunghi periodi di tempo, forse tutto il giorno, e le interazioni con le visualizzazioni dell'applicazione o i dati sottostanti innescano profondi cambiamenti nella gerarchia delle visualizzazioni. Ember è più grande di Backbone, ma grazie a Expires, Cache-Controlquesto conta solo sul il primo carico. Dopo due giorni di utilizzo quotidiano, quei 30.000 extra verranno oscurati dai trasferimenti di dati, prima se i tuoi contenuti includono immagini.

Backbone è ideale per applicazioni con un numero limitato di stati in cui la gerarchia di visualizzazione rimane relativamente piatta e in cui l'utente tende ad accedere all'app raramente o per periodi di tempo più brevi. Il codice di Backbone rimane breve e dolce perché presuppone che i dati che supportano il DOM verranno gettati via ed entrambi gli elementi verranno raccolti in memoria: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Le dimensioni ridotte di Backbone lo rendono anche più adatto a brevi interazioni.

Le app che le persone scrivono in entrambi i framework riflettono questi usi: le app Ember.js includono la dashboard web di Square , Zendesk (almeno l'interfaccia agente / ticketing) e lo scheduler di Groupon : tutte le applicazioni in cui un utente potrebbe passare tutto il giorno a lavorare.

Le app Backbone si concentrano maggiormente su interazioni brevi o casuali, che spesso sono solo piccole sezioni di una pagina statica più grande: airbnb , Khan Academy , la mappa e gli elenchi di Foursquare .

È possibile utilizzare Backbone per rendere i tipi di applicazioni che gli obiettivi di Ember (ad esempio Rdio ) da a) aumentando la quantità di codice dell'applicazione sei responsabile per i problemi evitare come le perdite di memoria o eventi zombie (Non consiglio personalmente questo approccio) oppure b) aggiungendo librerie di terze parti come backbone.marionette o Coccyx - ci sono molte di queste librerie che cercano tutte di fornire funzionalità di sovrapposizione simili e probabilmente finirai per assemblare il tuo framework personalizzato che è più grande e richiede più codice colla di se avessi usato solo Ember.

In definitiva la domanda su "quale usare" ha due risposte.

Primo, "Quale dovrei usare, in generale, nella mia carriera": entrambi, proprio come finirai per imparare qualsiasi strumento specifico per il lavoro che vorrai fare in futuro. Non chiederesti mai "Backbone o D3?"; "Backbone or Ember" è una domanda altrettanto sciocca.

Secondo, "Quale dovrei usare, in particolare, nel mio prossimo progetto": dipende dal progetto. Entrambi comunicheranno con un server Rails con la stessa facilità. Se il tuo prossimo progetto prevede un mix di pagine generate dal server con le cosiddette "isole di ricchezza" fornite da JavaScript usa Backbone. Se il tuo prossimo progetto spinge tutta l'interazione nell'ambiente del browser, usa Ember.


4
Ottima risposta, Trek. Volevo solo commentarlo qui Expirese Cache-Controlaiutare molto meno di quanto la gente pensi, specialmente in termini di dispositivi mobili che spesso li ignorano. Ricordo che una versione di iOS li ignorava completamente (ma ascoltava ancora il manifest della cache HTML5). Inoltre, questi valori di intestazione non sono utili durante la prima visita di un utente, che generalmente è il più critico per decidere se l'utente rimarrà e utilizzerà la tua app. Dire tutta quella differenza di 30kb di file non mi sembra un grosso problema. È una differenza di 30k grezza o minimizzata e zippata?
Mauvis Ledford

11
Se guardi le applicazioni reali che sono lo stile che Ember intende creare, scoprirai che non c'è modo di sfuggire a quei fastidiosi kbs. O provengono da Ember e il codice dell'applicazione è più piccolo, o provengono da plug-in backbone, o provengono da codice che scrivi tu stesso. Wunderlist , che penseresti sarebbero "semplici" orologi a circa 300kb di trasferimento. Immagino che sarebbe di dimensioni simili con Ember, forse più piccolo - non avendo mai scritto una copia esatta di Wunderlist non posso dirlo con il 100% di certezza.
Trek Glowacki

1
Sono d'accordo, la mia app backbone più popolare ha un clock di 178kb + modelli compressi e minimizzati. Sto solo sottolineando come non dovremmo fare affidamento sul caching del browser.
Mauvis Ledford,

2
Trek, sei a posto con la tua analisi dell'utilizzo di Backbone in app con modelli di utilizzo estesi e una complessa gestione dello stato. Ho vissuto l'esperienza di convertire un'app legacy in Backbone e ho dovuto fare esattamente quello che hai elencato. Avevamo bisogno di integrare Marionette e scrivere un sacco di codice collante per cose come il filtro pre / post route, mitigazione della perdita di memoria e una migliore gestione degli eventi.
Mike Clymer

9
"Non chiederesti mai a Backbone o D3" - certo, ma posso facilmente immaginare un progetto in cui userei D3 insieme a Backbone. Probabilmente è molto più difficile immaginare un progetto in cui Backbone ed Ember sono usati insieme su una singola pagina. Quindi, trovo la domanda "Backbone or Ember" abbastanza giusta. Ecco un altro post che ho trovato abbastanza informativo, perché confronta i due framework in modo più approfondito: net.tutsplus.com/tutorials/javascript-ajax/…
Shiprack

26

Per dare una risposta breve e semplificata: per un backend RESTful, al momento, dovresti usare Backbone.

Per dare una risposta più complessa: dipende davvero da cosa stai facendo. Come altri hanno già detto, Ember è progettato per cose diverse e si rivolge a un gruppo diverso di persone. La mia breve risposta si basa sull'inclusione del requisito RESTful.

Al momento, Ember-Data (che sembra essere il meccanismo di persistenza predefinito all'interno di Ember) è tutt'altro che pronto per la produzione. Ciò significa che ha alcuni bug e, soprattutto, non supporta gli URI annidati (/ posts / 2 / comments / 4556 per esempio). Se REST è il tuo requisito, dovrai aggirare questo problema per il momento se scegli Ember (cioè dovrai hackerarlo, aspettare, implementare qualcosa come Ember-Data da zero o non usarlo -molto RESTful URI). Ember-Data non fa strettamente parte di Ember, quindi questo è del tutto possibile.

Le principali differenze tra i due, a parte le dimensioni, sono sostanzialmente:

Ember cerca di fare il più possibile per te, in modo da non dover scrivere tanto codice. È molto gerarchico e, se la tua app è anche molto gerarchica, probabilmente andrà bene. Poiché fa così tanto per te, può essere difficile capire da dove provengono i bug e spiegare perché si sta verificando un comportamento inaspettato (c'è molta "magia"). Se hai un'app che si adatta naturalmente al tipo di app che Ember si aspetta che crei, probabilmente non sarà un problema.

Backbone cerca di fare il meno possibile per te in modo che tu possa ragionare su ciò che sta accadendo e costruire un'architettura che si adatti alla tua app (piuttosto che costruire un'app che si adatti all'architettura del framework che stai utilizzando). È molto più facile iniziare ma, a meno che tu non stia attento, puoi finire con un pasticcio molto rapidamente. Non fa cose come proprietà calcolate, eventi di auto-disassociazione, ecc e le lascia a te, quindi dovrai implementare molte cose da solo (o almeno scegliere le librerie che lo fanno per te), sebbene sia piuttosto l'intero punto.

Aggiornamento : sembra che, di recente, Ember ora supporti gli URI annidati, quindi suppongo che la domanda si riduca a quanta magia ti piace e se Ember sia adatto, architettonicamente, alla tua app.


5
"Fondamentalmente, non supporta gli URI annidati (/ posts / 2 / comments / 4556 per esempio)" Ecco il commit pertinente di un paio di settimane fa: github.com/emberjs/data/commit/… . Sa che può essere difficile stare al passo con un framework pre-rilascio in rapido movimento, ma dovremmo sempre mirare alla precisione quando parliamo con autorità e offriamo consigli!
Trek Glowacki

Figo, grazie. Ho aggiornato la mia risposta. Presumo che sia stato introdotto nella fusione delle grandi relazioni la scorsa settimana o giù di lì. Ho dato un'occhiata e letto le modifiche elencate ma non sono riuscito a trovare alcuna menzione di URL e i problemi che stavo monitorando erano ancora aperti quando li ho controllati. Grazie per aver sottolineato il commit: può essere difficile da individuare senza conoscerne già l'esistenza.
bengillies

È in effetti dalla recente fusione del ramo del miglioramento delle relazioni. Abbiamo seguito lentamente i vecchi problemi e li abbiamo chiusi questa settimana.
Trek Glowacki

3

Penso che la tua domanda sarà presto bloccata :) Ci sono alcune controversie tra i due framework.

Fondamentalmente Backbone non fa molte cose, ed è per questo che lo adoro: dovrai programmare molto, ma codificherai nel posto giusto. Ember fa molte cose, quindi faresti meglio a stare attento a cosa sta facendo.

La discussione sul server è una delle poche cose che fa Backbone e ci fa un ottimo lavoro. Quindi inizierei con Backbone e poi proverei Ember se non sei completamente soddisfatto.

Puoi anche ascoltare questo podcast in cui Jeremy Ashkenas, creatore di Backbone, e Yehuda Katz, membro di Ember, hanno una bella discussione


2
Grazie. Cosa puoi dire delle estensioni Rets di Ember. Utilizzare meglio i dati o le risorse? Puoi fare un semplice esempio di chiamata api rest?
Robin Wieruch

1
La risposta breve è che le biblioteche variano continuamente e non posso darti una risposta basata sulla mia precedente esperienza (l'ho fatto su me stesso per la valutazione). Penso che questo post vi dirà di più di quanto posso: stackoverflow.com/questions/8623091/ember-js-rest-api
Nicolas Zozol

1
Ho già visto questo post. Ecco perché ho chiesto :)
Robin Wieruch

2
@NicolasZozol quale podcast? collegamento?
Deepak

3
javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas da febbraio. Questo prima che diventi più chiaro che questi framework non esistevano realmente in arene sovrapposte. Puoi sentire Yehuda e Jeremy che parlano uno accanto all'altro, senza fare alcun confronto.
Trek Glowacki
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.