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

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

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.

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.

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