Ember.js ou Backbone.js para back-end Restful [fechado]

Eu já sei que ember.js é uma abordagem mais pesada em comparação com backbone.js. Eu li muitos artigos sobre ambos.

Estou me perguntando, qual framework funciona mais facilmente como front-end para um back-end de descanso de trilhos. Para backbone.js, vi diferentes abordagens para chamar um back-end restante. Para o ember, parece que tenho que incluir mais algumas bibliotecas como 'dados' ou 'recursos'. Por que existem duas bibliotecas para isso?

Então, qual é a melhor escolha? Não existem muitos exemplos para conectar o frontend ao backend também. Qual é um bom exemplo de trabalho para uma chamada de back-end para este:

URI: ../restapi/topics GET credenciais de autenticação: formato admin / secrect: json

Ao contrário da opinião popular, o Ember.js não é uma 'abordagem mais pesada' para o Backbone.js. São diferentes tipos de ferramentas que visam produtos finais totalmente diferentes. O ponto forte do Ember são os aplicativos em que o usuário mantém o aplicativo aberto por longos períodos, talvez o dia todo, e as interações com as visualizações do aplicativo ou dados subjacentes acionam mudanças profundas na hierarquia de visualizações. O Ember é maior que o Backbone, mas graças a isso Expires, Cache-Controlisso só importa na primeira carga. Após dois dias de uso diário, esses 30k extras serão ofuscados por transferências de dados, mais cedo se o seu conteúdo envolver imagens.

O backbone é ideal para aplicativos com um pequeno número de estados nos quais a hierarquia de visualização permanece relativamente plana e onde o usuário tende a acessar o aplicativo com pouca frequência ou por períodos mais curtos de tempo. O código do backbone permanece curto e agradável porque pressupõe que os dados que sustentam o DOM serão descartados e ambos os itens serão coletados na memória: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 O tamanho menor do backbone também o torna mais adequado para interações breves.

Os aplicativos que as pessoas escrevem em ambas as estruturas refletem estes usos: os aplicativos Ember.js incluem o painel da web da Square , o Zendesk (pelo menos a interface do agente / tíquete) e o agendador do Groupon : todos os aplicativos nos quais um usuário pode passar o dia inteiro trabalhando.

Os aplicativos de backbone se concentram mais em interações breves ou casuais, que geralmente são apenas pequenas seções de uma página estática maior: airbnb , Khan Academy , mapa e listas do Foursquare .

Você pode usar o Backbone para fazer os tipos de aplicativos que o Ember almeja (por exemplo, Rdio ) por a) aumentando a quantidade de código do aplicativo pela qual você é responsável para evitar problemas como vazamentos de memória ou eventos zumbis (eu pessoalmente não recomendo essa abordagem) ou b) adicionando bibliotecas de terceiros como backbone.marionette ou Coccyx - há muitas dessas bibliotecas que tentam fornecer funcionalidade de sobreposição semelhante e você provavelmente acabará montando sua própria estrutura personalizada que é maior e requer mais código de cola do que se você tivesse acabado de usar Ember.

Em última análise, a questão de "qual usar" tem duas respostas.

Primeiro, "O que devo usar, geralmente, em minha carreira": ambos, assim como você acabará aprendendo quaisquer ferramentas específicas para o trabalho que queira fazer no futuro. Você nunca perguntaria "Backbone ou D3?"; "Backbone or Ember" é uma pergunta igualmente boba.

Segundo, "Qual devo usar, especificamente, no meu próximo projeto": Depende do projeto. Ambos se comunicarão com um servidor Rails com igual facilidade. Se o seu próximo projeto envolver uma mistura de páginas geradas pelo servidor com as chamadas "ilhas de riqueza" fornecidas pelo JavaScript, use o Backbone. Se o seu próximo projeto empurra toda a interação para o ambiente do navegador, use o Ember.

Para dar uma resposta breve e simplificada: para um back-end RESTful, no momento, você deve usar o Backbone.

Para dar uma resposta mais complexa: realmente depende do que você está fazendo. Como já foi dito, o Ember foi projetado para coisas diferentes e atrairá um grupo diferente de pessoas. Minha resposta curta é baseada na sua inclusão do requisito RESTful.

No momento, o Ember-Data (que parece ser o mecanismo de persistência padrão do Ember) está longe de estar pronto para produção. O que isso significa é que ele tem alguns bugs e, fundamentalmente, não suporta URIs aninhados (/ posts / 2 / comments / 4556 por exemplo). Se REST for o seu requisito, você terá que contornar isso por enquanto se escolher o Ember (ou seja, você terá que hackear, esperar, implementar algo como Ember-Data do zero por conta própria, ou não usar -very-RESTful URIs). O Ember-Data não faz parte estritamente do Ember, então isso é totalmente possível.

As principais diferenças entre os dois, além do tamanho, são basicamente:

O Ember tenta fazer o máximo possível por você, para que você não precise escrever tanto código. É muito hierárquico e, se seu aplicativo também for muito hierárquico, provavelmente será um bom ajuste. Como ele faz muito por você, pode ser difícil descobrir de onde vêm os bugs e raciocinar por que um comportamento inesperado está acontecendo (há muita "mágica"). Se você tiver um aplicativo que se encaixa naturalmente no tipo de aplicativo que Ember espera que você crie, isso provavelmente não será um problema.

O Backbone tenta fazer o mínimo possível para que você possa raciocinar sobre o que está acontecendo e construir uma arquitetura que se ajuste ao seu aplicativo (em vez de construir um aplicativo que se ajuste à arquitetura da estrutura que você está usando). É muito mais fácil começar, mas, a menos que você tome cuidado, pode acabar com uma bagunça muito rapidamente. Ele não faz coisas como propriedades computadas, eventos de desassociação automática, etc e deixa-os por sua conta, então você precisará implementar muitas coisas você mesmo (ou pelo menos escolher bibliotecas que façam isso para você), embora isso seja antes, todo o ponto.

Atualização : parece que, recentemente, o Ember agora oferece suporte a URIs aninhados, então suponho que a questão se resume a quanta magia você gosta e se o Ember é um bom ajuste, arquiteturalmente, para seu aplicativo.

Acho que sua pergunta será bloqueada em breve :) Existem algumas controvérsias entre os dois frameworks.

Basicamente, o Backbone não faz muitas coisas, e é por isso que eu adoro: você terá que codificar muito, mas codificará no lugar certo. Ember faz um monte de coisas, então é melhor você observar o que ele está fazendo.

A discussão do servidor é uma das poucas coisas que o Backbone faz, e faz um ótimo trabalho com ela. Então, eu começaria com o Backbone e depois tentaria o Ember se você não estiver totalmente satisfeito.

Você também pode ouvir este podcast onde Jeremy Ashkenas, criador do Backbone, e Yehuda Katz, membro do Ember, têm uma boa discussão