演習として、Rails アプリケーションの前面にあるすべての側面を Backbone.js に置き換えるつもりです。計画の一部には、CSS に至るまですべてを再設計することが含まれます。
私が苦労している問題は、テンプレートとビューの責任を委任することです。
新しいフロントエンドを完全にバックボーンに実装して、Rails のみを API として使用するメリットはありますか?
アプリケーションの HTML 要素の処理に関して、Rails と Backbone の間で適切なバランスを取るにはどうすればよいでしょうか?
誰もこれに対する答えを投稿するつもりはないようですので、私は2セントを1つの観点として提供します（railsとbackbone.jsをうまく連携させる方法の問題については他の場所で書いています：railsとバックボーンが連携して動作します）。
この状況のほとんどの人は、レールビューを完全に削除し、すべてをbackbone.jsに移行する傾向があります。
これは私が今取り組んでいるプロジェクトでやったことです。
これはイベントの自然な流れであり、特に、backbone.jsと構造化されたjavascriptで実行できるすべての複雑で興味深いことに慣れると、標準のステートレスHTMLページに戻って実装することが難しくなります。
上記にリンクされている他の回答で述べたように、ただし、HTMLビューとステートレスレイヤーを完全に破棄するにはコストがかかります。GET私の場合、アプリが特定のレベルの機能に達したときにのみ、リクエスト用の非js対応ブラウザー用の純粋なHTMLページを追加し直すつもりです。ユーザーがJavaScriptを有効にしていない限り（またはJSON APIを使用したい場合を除いて）、サポートPOSTやリクエストは行いません。PUT
それが私が打ったバランスです。データにアクセスするためのステートレスHTML（JSなし）ですが、データの投稿/変更にはJSが必要です。選択は、ユースケースとターゲットユーザーによって異なります。
もう1つ言及するのは、プロジェクトでRails HTMLビューをしばらく使用している場合、backbone.jsに切り替えるために必要な初期オーバーヘッドの準備ができていない可能性があるということです。これは単にHAMLをERBに交換するだけではありません。ステートレスフロントエンドからステートフルフロントエンドに移行しているため、これは潜在的に大きな変更です（アプリの複雑さによって異なります）。私自身は、その変化の深さに少し準備ができておらず、切り替え後にアプリを軌道に戻す前に、多くの追いつく必要がありました。そして、最小限の機能がすでに導入されている状態で、非常に早い段階で切り替えを行いました。
とにかく、ほんの少しの考え、彼らが助けてくれることを願っています。