JavaScriptフレームワークは数多いが、結局どれを選んだらよいのかよくわからん、ということはよくある。
今回は、メジャーどころの三大フレームワークを使ってまったく同じ機能のTodoアプリを作成してみました。
そのソースコードは、下記の通りjsFiddleで参照＆稼働させてみることができます。これで（きれいごとではない）クセやコード量などを感じてみてもらえればよいと思います。
| FW | jsFiddle | 所感 |
|---|---|---|
| Backbone.js | Todo① | 大規模開発向きか。簡単なアプリなら割に合わない |
| Knockout.js | Todo② | わかりやすい。面倒な面はあるが、不可解でドツボにはまることがあまりない |
| Angular.js | Todo③ | 便利。ただ、自由度が高すぎて統制をかけたい場合は向かないかも |
Todoリストの機能
1.テキストボックスから、Enterで追加できる
2.登録したTodoはダブルクリックで編集可能になり、Enterで編集確定できる
3.登録されているTodoの総件数がフッターに表示される
4.完了したTodoがある場合、それらをリストから消すボタンが表示される
5.全選択/解除を行うチェックボックスがある
個人的な結論
趣味開発で使うならAngular.js・仕事で使うならKnockout.jsをお勧めしたい。
まず、フレームワークを選択する際は、以下3つの選択基準を持つとよいと思う。
1.開発の規模
大規模ならBackbone.jsはお勧めできる。
書き方が決まっていて、チュートリアルに目を通せば(面倒なのは置いておいて)何を作らなければならないかは簡単に理解できる。そこそこの人数で長い時間の開発を行うなら、UIチームはアプリケーションとView、サーバーサイドはModelとCollection、という感じで分業もしやすいと思う。UIバインディング型のフレームワークは性質上画面DOMありきなので、バインディング部分のモジュール化は結構頭を使う必要があると思う。
2.フレームワークに求めるもの
コードを構造化したいのか、生産性を上げたいのか、両方の場合どちらの優先度が高いのかを考えるとよいと思う。
生産性の向上ならUIバインディング型のKnockout.jsやAngular.jsがお勧めだ。
これらは、普通に使ってて便利！と思える瞬間が多い。個人で開発する場合構造化に迫られる人はあんまりいないと思うので、そういう場合にも良い。
3.趣味
使い始めるとその後拘束されることになるので、なんだかんだ言って第一印象は重要だ。今回は実際に書いたコードを掲載しているので、参考になれば。
以下は、所感の詳細。
Backbone.js
確かにこれを使えばJavaScriptはきれいに書ける気がする。が、手間はかなりかかる。
今回Todoリストを表示するのに、まずTodoのModel、これを表示するためのView、リスト表示するためのCollection、そして最後にアプリケーション、と4つもオブジェクトを作る必要がある。
将来的な使いまわしを考えるならこれが活きてくるのかもしれないが、そうするとそこそこ大規模でないと割に合わないと思う。あと「軽い」とよく言われるがその分他ライブラリ(jQuery/Underscore.js etc)に依存しているので、そこは要注意(特にjQueryはすでにプロジェクトで使っているバージョンがあったりするので)。
Knockout.js
わかりやすい、というのが第一印象。DOMとJavaScript側ViewModelの対応関係は見通しがよく、理解しやすい。
イベント/テンプレートバインディングなど効果の実感できる機能がすぐに使え、JavaScriptフレームワークを初めて使う、またチームで展開してみたい、という時にお勧めできる。
独自タグがないのでHTMLはHTMLとして完成されるのもポイントが高い(他のフレームワークは、そんな属性ない警告や不明タグ警告がそこそこ出る)・・・が、その分煩雑な記述が要求されることも多い(特にIF文)のは注意。
Angular.js
形としてはKnockout.jsに近いが、より簡単にかける。
具体的に簡単な点としては、Knockout.jsだと単純に値を書きたい場合でも<span data-bind="text:hoge"></span>みたいな形でDOMを経由しないといけないが、Angular.jsでは{{hoge}}と一発でかける(ただ、逆にng-click="function(){xxx}"みたいにはかけないので、一長一短?)。
今回のTodoアプリでは、選択しているのが1つなら"item"、複数なら"items"にするというようなしちめんどくさい機能があるのだが、こういう細かい実装があるときこの差が結構出てくる。
ただ、自由に書ける反面統制がききにくそうで、そこは注意が必要と感じた。チームで使うなら、Model定義とtemplateについては要ルール整備と思う→カオスにならないためということで、まとめました。
また、Backbone.jsにおけるUnderscore.js、Knockoutにおけるko.utilsみたいなサポートライブラリがないので、「配列から画面で選択された要素を削除する」みたいな簡単な処理でも書くのが面倒なことがある(今回のTodoリストでも・・・)。