ember.jsは、backbone.jsとは対照的に、より重いアプローチであることを私はすでに知っています。私は両方についてたくさんの記事を読みました。
Rails Restバックエンドのフロントエンドとして、どのフレームワークがより簡単に機能するかを自問しています。backback.jsの場合、RESTバックエンドを呼び出すためのさまざまなアプローチを見ました。残り火については、「データ」や「リソース」などのライブラリをさらに含める必要があるようです。なぜこれに2つのライブラリがあるのですか？
それで、より良い選択は何ですか？フロントエンドとバックエンドを接続する例もたくさんあります。これに対するバックエンドREST呼び出しの良い実例は何ですか？
URI：../restapi/topics GET認証クレデンシャル：admin / secret形式：json
一般的な意見に反して、Ember.jsはBackbone.jsに対する「より重いアプローチ」ではありません。これらは、まったく異なる最終製品を対象とするさまざまな種類のツールです。Emberのスイートスポットは、ユーザーがアプリケーションを長期間、おそらく1日中開いたままにし、アプリケーションのビューまたは基になるデータとの対話がビュー階層の大幅な変更をトリガーするアプリケーションです。EmberはBackboneよりも大きいですが、おかげでExpires、Cache-Controlこれは最初のロードでのみ問題になります。毎日2日間使用した後、コンテンツに画像が含まれている場合は、その余分な30kがデータ転送によって影が薄くなります。
バックボーンは、ビュー階層が比較的フラットなままで、ユーザーがアプリに頻繁にまたは短時間アクセスする傾向がある、状態の数が少ないアプリケーションに最適です。バックボーンのコードは、DOMをサポートするデータが破棄され、両方のアイテムがメモリ収集されることを前提としているため、短くて甘いままになります：https ://github.com/documentcloud/backbone/issues/231#issuecomment-4452400バックボーンのサイズが小さいため、簡単な操作にも適しています。
両方のフレームワークで作成するアプリは、これらの用途を反映しています。Ember.jsアプリには、SquareのWebダッシュボード、Zendesk（少なくともエージェント/チケットインターフェイス）、Grouponのスケジューラーが含まれます。ユーザーが1日中作業する可能性のあるすべてのアプリケーションです。
バックボーンアプリは、短いまたはカジュアルなインタラクションに重点を置いています。これは、多くの場合、より大きな静的ページのほんの一部です：airbnb、Khan Academy、Foursquareのマップとリスト。
Backboneを使用して、Emberがターゲットとする種類のアプリケーション（Rdioなど）を作成できます。a ）メモリリークやゾンビイベントなどの問題を回避するために、担当するアプリケーションコードの量を増やします（このアプローチは個人的にはお勧めしません）。またはb）backbone.marionetteやCoccyxなどのサードパーティライブラリを追加する-これらのライブラリの多くは、すべて同様の重複機能を提供しようとし、おそらく、より大きく、より多くのグルーコードを必要とする独自のカスタムフレームワークを組み立てることになります。 Emberを使用したばかりの場合。
最終的に、「どちらを使用するか」という質問には2つの答えがあります。
まず、「私のキャリアでは、一般的にどちらを使用する必要がありますか」：どちらも、将来やりたい仕事に固有のツールを学習することになるのと同じです。「バックボーンまたはD3？」と尋ねることは決してありません。「バックボーンまたはエンバー」も同様にばかげた質問です。
次に、「具体的には、次のプロジェクトでどちらを使用する必要がありますか」：プロジェクトによって異なります。どちらもRailsサーバーと同じくらい簡単に通信します。次のプロジェクトに、サーバーによって生成されたページと、JavaScriptによって提供されるいわゆる「豊かな島」が混在している場合は、Backboneを使用します。次のプロジェクトですべてのインタラクションがブラウザ環境にプッシュされる場合は、Emberを使用してください。
簡単に簡単に答えると、RESTfulバックエンドの場合、現時点ではBackboneを使用する必要があります。
より複雑な答えを与えるために：それは本当にあなたがしていることに依存します。他の人が言っているように、Emberはさまざまな目的のために設計されており、さまざまな人々にアピールします。私の簡単な答えは、RESTful要件を含めることに基づいています。
現時点では、Ember-Data（Ember内のデフォルトの永続化メカニズムのようです）は、本番環境に対応しているとは言えません。これが意味するのは、かなりの数のバグがあり、重要なことに、ネストされたURI（/ posts / 2 / comment / 4556など）をサポートしていないということです。RESTが要件である場合、Emberを選択する場合は、当面はこれを回避する必要があります（つまり、Emberをハックするか、待つか、Ember-Dataのようなものを最初から実装するか、使用しないかのいずれかです。 -非常にRESTfulなURI）。Ember-データは厳密にはEmberの一部ではないため、これは完全に可能です。
サイズを除いて、2つの主な違いは基本的に次のとおりです。
Emberは、できるだけ多くのコードを記述しなくても済むように、できる限りのことをしようとします。これは非常に階層的であり、アプリも非常に階層的である場合は、おそらく適切です。それはあなたにとって非常に多くのことをするので、バグがどこから来ているのかを理解し、予期しない動作が起こっている理由を推論するのは難しいかもしれません（たくさんの「魔法」があります）。ただし、Emberが構築することを期待しているタイプのアプリに自然に適合するアプリがある場合、これはおそらく問題にはなりません。
Backboneは、（使用しているフレームワークのアーキテクチャに適合するアプリを構築するのではなく）何が起こっているのかを推論し、アプリに適合するアーキテクチャを構築できるように、できる限りのことを行わないようにします。始めるのはずっと簡単ですが、注意しないと、すぐに混乱してしまう可能性があります。計算されたプロパティや自動バインド解除イベントなどは実行せず、それらはユーザーに任されているため、多くの機能を自分で実装する必要があります（または、少なくともそれを実行するライブラリを選択する必要があります）。むしろ全体のポイント。
更新：最近、EmberはネストされたURIをサポートしているようです。そのため、問題は、どの程度の魔法が好きか、Emberがアーキテクチャ上アプリに適しているかどうかにかかっていると思います。
あなたの質問はすぐにブロックされると思います:)2つのフレームワークの間にはいくつかの論争があります。
基本的に、Backboneは多くのことを実行しません。そのため、私はそれが大好きです。多くのコーディングが必要になりますが、適切な場所でコーディングします。Emberは多くのことを行うので、Emberが何をしているのかを監視することをお勧めします。
サーバーディスカッションは、Backboneが行う数少ないことの1つであり、Backboneで素晴らしい仕事をします。したがって、Backboneから始めて、完全に満足していない場合はEmberを試してみます。
また、Backboneの作成者であるJeremyAshkenasとEmberのメンバーであるYehudaKatzが素晴らしいディスカッションを行うこのポッドキャストを聞くこともできます。