個人的にはCoffeescriptは大丈夫ですが、私はRailsアプリのサポートプレーヤーであり、ロジックの大部分ではありません。私が見ることから、Backbone.jsやSpine.jsをRailsで使用する場合、まだ多くのロジックを複製する必要があります。これらのフレームワークのメリットを得ることはできませんか、または本質的にはラックマウント型のpjaxを使用してリアルタイム更新用のjsを備えた単一のページアプリですか？本当に、単一ページアプリケーションのためにRailsでBackbone.jsやEmber.jsのようなMVCフレームワークが必要ですか？
どのように達成したいですか？もうページは更新されませんか？その場合、rack-pjaxが動作するはずです。スピードや応答性の高いUIが必要な場合は、良い解決策にはならないでしょう。
サーバーの負荷と複雑さが大幅に軽減され+ viewlogic & serverlogicの間に素晴らしい抽象が存在するため、単一ページのアプリケーションが優先されます。
サーバーは基本的にAPIになり、クライアントはすべてのAPIデータをブラウザに表示します。このようにして、サーバーは大幅に単純化され、行う作業が大幅に減ります。
クライアント側でも、多くの改善点が見られます。適切に実行された場合、データに対して行われたイベントや状態の変化に基づいて継続的に再表示されます。このアプローチでは、UIレイヤでの結合（および複製）が大幅に少なくなり、ユーザーにとってより反応性の高いUIが実現します。 （勝つ！）
をあなたはそれについてはあまり気にしない場合は、先に行くと利用pjax :)
それは、単一ページのアプリケーションへの既存のサーバー・サイドビューレンダリングアプリを書き換えても覚えておいてくださいJSフロントエンドを使用するのは難しいビジネスです。おそらく大改訂に終わるでしょう。 JSのフロントエンドにページの一部だけを書くことも試してみることができます。
クライアント側のレンダリングは通常、サーバー側のレンダリングを置き換えるべきではありません。ミラーリングするだけです。あなたが古いブラウザを気にせず、検索ボットでクロール可能でない限り、 – devth
最近、こうしたケースを処理するhttps://github.com/airbnb/rendrなどのソリューションがあります。まだ使用していない。 – SpoBo
これは要件によって異なります。コンテンツが重い場合は、ミラーリングする必要があります（pjaxがこれより優れている理由です）。それがウェブアプリの場合は、古いブラウザやSEOをねじ込みます。必要なし。古いブラウザのほとんどはサポートされていません。それは時代遅れの議論です。 – Oddman
rack-pjaxはブラウザがリクエストごとにページをリフレッシュするのを防ぎますが、サーバーは依然としてリクエストごとにHTMLページ全体を送信しています。あなたの目標がページリフレッシュのない「シングルページ」アプリである場合は、rack-pjaxは動作しますが、読み込みの代わりにJSONを扱うフレームワークを使用すると、多くの帯域幅を節約し、ページ全体
単純なアプリの場合は、バックボーンやスパインなどから始めることをおすすめします。より複雑なアプリケーションの場合、小さなフレームワークで多くの定型的なコードを書いていることがすぐわかります。EmberやCappuccinoのようなものをあなたのために大部分を処理する方が良いでしょう。
1ページのアプリケーションが必要な場合は、論理の一部またはほとんどがフロントエンドにあると考えられます.JavaScriptで直接書かれているか、またはcoffeescriptで書かれ、javascriptにコンパイルされています。もちろん、サーバー上で特定のロジックが必要です（検証のように、JSコードの検証ロジックを使用しても、サーバーに悪いデータを送信し、送信することがあります）。
「必要ですか？いいえ、JavascriptはMVCなしで書かれています。それは有益でしょうか？おそらく。それはあなたのために過労ですか？誰もあなたが言うことはできません。 – deceze
他にもApp Engine、Pajamas、Cappuccinoのオプションがあります。通常、単一ページのWebアプリケーションは、より大きなフレームワークを使用して実行されます。もちろん、あなた自身を書くことが簡単なら、それを学ぶのは簡単です！または、単一ページのアプリケーションが比較的単純な場合は、javascriptとajaxを使用します。 –