2012年6月3日日曜日

Ember.jsのRoutingに期待している

Ember.jsのサイトがリニューアルされてドキュメントが増えたよ!

Check: http://emberjs.com/

GUIDEというのが増えていて、他のMVCフレームワークと違いEmber.jsはどういう設計になっているかを図解で説明してくれているのと、Railsとの違いも書いてあってとても参考になります。ちなみにRailsはオワコンではありませんので、その辺は誤解のないように。


Ember.js 1.0でリリースされるであろうRouting

Routingがうまくできれば、RailsやSinatraのようにコードを簡潔にかけると思うのですが、クライアントサイドの場合は難しそう。マッピングとディスパッチを簡単にできればいいけど、そこにステートがくっついてくるのかなーというイメージでいました。たぶん、そのイメージは正解で、Ember.jsではEmber.stateManagerとEmber.Stateを使って実現するようです。


他にもリンクを

Ember.jsの情報は追いにくいので、個人的に有用だと思ったリンクを載せときます。


しかしJSはRubyより記述量が多いなー

Routingのサンプルを見ても、ちょっとごちゃごちゃしてるなーって思っちゃいますね。CoffeeScriptとか出てきたのはすごく納得のいくことですが、CoffeeScriptでやるならRubyでいいし、何かはまるとデバッグしずらそうと思って避けちゃいます。簡単なやつならCoffeeScriptで書くこともあるけど。JSは進化が遅いというか、もうこのままなんでしょうかね。Emberとかそういったものを使わずに作られているSPAのJSは機能の割にコード量が多くて可視性も悪いものが多いんじゃないかな。(可読性とは別)

サーバサイドと違い、ブラウザで動く言語は指定できません。JavaScriptオンリー。しかもブラウザとバージョンごとに実装もバラバラ。大変ですね。JSはAjax到来により再評価されて高評価を得ましたが、それは誤解されていたという点の裏返しもあると思います。

ブラウザで動く言語はこれしかないので、今後もたくさんのプログラマーがJavaScriptに束縛されると思います。まるで安いレンタルサーバでPHPしか動かない時のよう。フラストレーションは溜まるでしょうね。まだサーバの方はPerlや他の言語の選択肢を作ることはできるのですが... どの言語でもあると思いますが、残念なJSコードは量産されるでしょうね。PHPからJSに移った人が最初の頃はPHPをdisりますが(過去の自分がそうw)、JSも同じ流れになるだろうと睨んでいますw

それと、マルチデバイス対応を考えると、なんでもJavaScript(クライアントサイド)でやる(ビューの生成とか)という方針はまずいです。もさもさ動くようであればユーザエクスピリエンス的に良くないですね。そもそもユーザのマシンに負荷を与えるというのもどうなんだろう?と考えることも大事だと思います。SPAの本来の目的って何でしょうか。サーバ負荷の削減だけが目的ではないはず。きちんとその辺は吟味した上で使って行きたいですね(プロダクトでは)

だらだら書いてしまったけど、Ember.jsに期待している!