結論: Javascriptの乱用をやめるのが一番。
はじめに書いておきますがしょうもない話です。
結論、開発者としてはどのような方向性でやるべきか、を書いています。
JS多い時代でのフレームワークの根本的な問題云々のことは書いてません。
さて、現状、モバイルにおいて、Javascriptでまともに動くものを作ることは難しいです。
Twitterから引き抜いた超優秀なWebエンジニアを多数抱えるMediumですら、未だにモバイルで多数のバグを抱えています。
超優秀なエンジニアを世界一抱えているであろうGoogleのGmailですら、モバイル版のWebはすぐクラッシュします。また、自前スクロールに致命的なバグも抱えています。
正確には「UIが不審な挙動をする」ですが、エンドユーザにとっては同じことで、「バグ」です。
サーバサイドで起こるバグと同じ程度、いやそれ以上に、サービスに影響を与えます。
####UIのバグ
UIのバグは計測が難しいこともあり、あまり意識されることがありません。
サーバサイドの例外をキャッチして計測している人は多いですが、フロントエンドの例外をキャッチしている人は珍しい部類に入ると思います。
現在ではユーザの報告に頼るところが大きいでしょう。
また、UIの応答性についても言及する必要があります。
つまり、ユーザが操作したと感じた瞬間から、何ミリ秒以内に操作が完了するのか。
これも、サーバサイドのパフォーマンスをNew Relic等で計測している人は多いですが、「操作」に関しての応答性を取っている人を、私は見たことがありません。
遅いUIも、ユーザには「UIの挙動不審」であり、バグと同じです。
フロントエンドにJavascriptを乱用することは、常にこれらのデメリットを伴います。
また、冒頭で述べた通り、現状モバイル上でまともに動作するリッチなUIをJavascriptで「ちゃんと」実現することは、非常に難しい。
時価総額1兆円をゆうに超えるTwitterですら、そのモバイルWebはすぐにクラッシュし、すぐにスクロールがおかしくなるゴミです。
クラッシュは最悪のバグです。
iOSのブラウザはクラッシュしたらクッキーが吹き飛び、再度ログインをさせられるので更に業が深い。
Javascriptたくさんは、常にこの最悪のバグとの付き合いであることを意識したほうがいいです。
####なので
結論、現状Javascriptをたくさん書くことは、費用対効果が見合いづらい。
ほとんどのJS Heavyなサイトは、JSで実現される「操作感」よりも、JSのバグが産み出すユーザ離脱や、JSで産み出されるUI遅延のほうが大きいのが現実です。
JSで速度を向上させることを狙っているサイトでも、初期ロードが長かったり、JSのパース自体で端末の操作に遅延が生じ、結果逆に遅くなっていることも多いです。
そして、メンテナンスの問題があります。
現状のエコシステムでは、Javascriptコードの見通しが非常に悪い。
「RailsでJS辛い問題」です。
「避けることが出来る面倒は避ける」ことは常に正しいです。
有限のリソースを使って戦う必要はありません。
Javascriptを書かないにこしたことはありません。
特に、ロジックにJavascriptを噛ませるのは泥沼への一歩目だと言ってもよいです。
ドキュメントもされにくいし、テストもされにくい、構造化もされにくいことが相まり、一瞬で泥沼になります。
JavascriptライブラリはUIコンポーネントやTurbolinks, FastClick等十分テストされていて、かつロジックに一切絡まないものを使いましょう。
特にTurbolinksは良いです。ロジックに絡まない唯一のパフォーマンス向上手段といってもよい。
UIコンポーネントに関しては、例えばカレンダーとか標準のUIゴミなのでJSライブラリを使うのは良い判断だと思います。疎結合になるよう上手くRailsと連携しましょう。
自身のUIをJSで書けという話ではないです。
Javascriptは実行環境により実行結果が異なる可能性のあるクソ言語であることを思い出した方がいいです。（言語自体は悪くないです。）
使うべきところは使い、使わなくてもいいところは避ける。
適材適所でいきましょう。
当たり前の話になりましたが、JSが快適に書けすぎる環境が整ってしまったがために乱用してしまいがちになりましたので、定期的に見直すことは必要だという話でした。
####GitHubは
GitHubなどはよく考えていて、Javascriptも多数使っていますが、使わなくて済む部分は使うことを避けています。
リポジトリのStarボタンなどは、POSTを発行するただのリンクです。
ここはつい簡単だからといってJavascriptで書こうとしてしまいがちです。が、GitHubはそれを避けサーバサイドでやっている。
Railsだけで出来ることはRailsでやろうという指針が垣間見えます。
（GitHubがRailsかどうかは知りません。）
GitHubのような巨大なサイトだと、Javascriptの量もとんでもないことになりますので、大変良い判断だと思います。
####まとめ
以上、無駄にJavascriptをたくさん書くことを考え直す必要があるな、と思った次第です。
特にクライアントMVCは泥沼へ百歩入ってると個人的に思います。
書くまではいい。書くまでは。その後は知らん。
####APIに関する問題
これは今後RailsのエコシステムにおいてもJSON Schema等で解決されていくでしょうし、絶賛contribute募集中なので突っ込める方は突っ込みましょう。
成熟されるまでは、サーバサイドもクライアントサイドも不必要なコードを書かずに済ませる決定的な手段はありません。
サーバサイドは、Concernで上手くコード重複をかわす等、上手くやりましょう。あまり規約的ではありません。
クライアントサイドは、iOSならRestKitとか使って上手くコードを書かずにやるのがいいでしょう。面倒くさくなるのでRESTから逸脱するのは避けたほうがいいです。
または、Parse.comのiOSクライアントみたいな、自由度高めでイイ感じにRESTリクエストを発行するクライアントを書いても良いと思います。
Appが主でParse.comを使うことが出来るなら、使いましょう。外しません。
API開発しながらAPIクライアント書いたりして頑張る苦行は避けたほうがいい。
特にPush通知とかStoreとか独特すぎて死にたくなるの必至なので。
####結論
レールに乗ろう