MVCフレームワークの選択基準と主要フレームワークの特徴

Toru Hosokawa

twitter:@anton0825

facebook:toru.hosokawa1

github:hosokawa0825

blog:http://d.hatena.ne.jp/anton0825/

2012.10.1

JavaScriptのMVCフレームワークが増えている

Backbone.js, Angular.js, Spine, etc…

FWを選ぶのが大変！

FWの調査手順−１

• 作るアプリの要件を洗い出す

  規模

  複雑度

  特殊な要件（特殊なUI、リアルタイム通信など）

• 各FWの特徴を一覧にまとめる

  FWの特徴一覧を後でお見せします

  情報元：Journey Through The JavaScript MVC Jungle

FWの調査手順−２

• FW間の比較、アプリの要件とFWの機能の比較（Fit Gap分析）を行い、候補を数個まで絞る

  以下の項目を確認する。

  ・コミュニティは大きいか？

  ・十分なドキュメントがあるか？

  ・ファイルサイズが大きすぎないか？

  ・FWを使ったプロダクトがあるか？

  ・FWで何が出来るか？FWを拡張しなければ要件を満たせないか？

  ・FWは柔軟か、または特徴的な機能があるか？

FWの調査手順−３

• TodoMVCでコードを見比べて、写経してみる。ここで候補を２，３個まで絞る

  TodoMVC

  

FWの調査手順−４

• デモアプリを各FWを使って書いてみる

  使ってみて「しっくりくる」ことが大事

  書いてみないとわからないことは沢山ある

各FWのメリット・デメリット

Backbone.js

メリット

• コミュニティが大きい。StackOverflowにノウハウが蓄積されている。FWの問題点はコミュニティによってすぐ解決される。継続的に開発されている。
• 実績は最も豊富（SoundCloud、LinkedIn、DocumentCloudで使われている）
• ドキュメント豊富。
• シンプル、軽量。コアコンポーネントはコレクション、モデル、ビュー、ルーターの４つだけ。
• シンプルなのでアーキテクチャを変更しやすい。
• RESTfulAPIを使ってサーバ上のデータを操作できる。
• モデル、ビュー、イベント、テンプレート、ルーティング機能がある。
• モデルとビューをバインド出来る。
• MVVMパターン
• Marionette、VertebraeなどのBackbone.jsをベースとしたFWが作られている。
• おまじないを沢山書く必要があるが、そのかわり黒魔術は少なめ。好きなようにアーキテクチャを組める。
• Underscore,jQuery,Zeptoと統合されている。
• シンプルで、チュートリアルが豊富なため勉強しやすい。とりあえずMVCフレームワークを勉強してみたいならコレ。

Backbone.js

デメリット

• extendメソッドがいまいち。これは親オブジェクトのプロパティを子オブジェクトにコピーする。プロトタイプ継承を使わない。
• 変化が激しいため、一ヶ月前の記事やチュートリアルに書かれている内容がもう使えなかったりする。
• ビューとモデルのバインディングを手動で管理する必要がある。モデルの一部が変更されたらビュー全体が更新されてしまう。
• RESTfulAPIを使って複数件のデータを一括登録・更新することができない。（これはRESTの問題ではあるが）

Extjs

メリット

• UIコンポーネントが非常に豊富。生のHTMLを書くことはほとんどない。
• 複雑なUIを比較的簡単に作れる。
• 業務システムを作るにはベストなフレームワークと思われる。
• Sencha Architectというツールによって、UIをGUI環境で作れる。
• モバイル用FWのSencha Touchがあり、Extjsと似ているためモバイル用アプリを作りやすい。
• 使えるようになるまでは比較的早い。
• MVCパターンを使うよう半ば強制されるのでアプリの構造がきれいになりやすい。パッケージ構造とフォルダ・ファイル構成が一致する。

デメリット

• HTMLを基本的にすべてフレームワークが生成するため、どんなHTMLが生成されるかが把握しづらい。SEOのためにHTMLを最適化するといったことがしづらい。CSSフレームワークが使いづらい。
• ライセンスの条件は厳しく、わかりづらい。
• パフォーマンスが悪い。
• ファイルサイズが大きい。minify,gzip済みで380KB程度
• ほぼすべてのHTMLをJavaScriptで生成するため、そのままではクローラブルでない（Googleなどの検索エンジンから検索できない）

Ember.js

メリット

• 導出項目と導出元の項目の依存関係を設定できる
• 双方向バインディング
• CoCによりモデルの属性間のバインドやモデルとビューのバインドが楽に出来る。コードが少なくて済む。
• 実績豊富（Square Inc.など）
• ドキュメント豊富。
• テンプレートエンジンのHandlebarsと統合されている。
• ネイティブアプリぐらいリッチなWebアプリが作れる。
• MVCパターン
• RESTfulAPIを使ってサーバ上のデータを操作できる。
• 開発者のYehuda Katz(Rails Core Teamの人)は実績があるので信頼できる。

デメリット

• バージョンが1.0未満なので今後仕様が変わる可能性がある。特にrouterとEmber data
• Backbone.jsなどに比べてドキュメントが不足している。FWのコードを調べて使い方を把握する必要がある。
• チュートリアルなどの学習リソースも少ない。入門者はつらい。
• 黒魔術使いまくりなのでちょっと怖い。分析が難しい不具合が起こるかも。。
• エラーメッセージがわかりにくい。
• コミュニティが小さい。
• 永続化機能が弱い。localStorageを使ったり、RESTfulAPI経由でデータをサーバと同期したりする機能が無い。

KnockoutJS

メリット

• 公式チュートリアルがよくできている
• 双方向バインディング
• dependency trackingによって自動的に導出元の項目が変更されたら導出項目も変更される
• 複雑で、動的なUIを作れる
• 好きなFWと一緒に使える
• 既存のアプリに組み込むことも簡単
• テンプレートエンジンを持つ
• 拡張しやすい
• Collection Viewを使うとViewのソートが簡単にできる。
• カスタムイベントが利用できる
• データバインディングが使いやすい

デメリット

• アプリの規模が大きい場合、APIが使いづらくなりそう。
• アプリを構造化するのが難しい。ビューモデルはあるが、正しく構造化されたアプリを作るのが難しい。

AngularJS

メリット

• ヘッドレスブラウザが付属していて受け入れテストが簡単にできる。例：アプリ テストコード テスト結果
• カスタムHTMLタグでビューモデルとDOMを紐付ける。ビューモデルにセレクタを書かないため、ビューモデルとDOMが疎結合になる。
• 双方向データバインディングが強力。イベントを気にせずモデルのデータを正しくすることに集中できる。
• ユーザがカスタムタグを定義できる。それによって複雑な機能が簡単に実現できる。
• DI機能でサーバとの通信などをモックに置き換えて簡単にテストできる。
• モデル、ビュー、コントローラ、ルーティング、テンプレート機能がある。
• Web Componentsのような先進的なWebプラットフォームの機能を取り入れている
• アプリケーションテンプレート生成ツールがある(angular-seed)
• FWのファイルサイズが小さい。テンプレートエンジンは文字列をDOMに変換するのではなく、DOMを直接テンプレートとして使用するのでパフォーマンスがいい。
• モデルの変更イベントが連続した場合、イベントの発生を間引くためパフォーマンスがいい。ちなみにknockoutjsは間引かないらしい。
• モダンブラウザのみサポートする場合はjQueryがなくても動く。
• わかりやすい、使いやすい。
• ドキュメントが豊富。
• スコープがDOM階層と一致している。
• Chrome拡張のBatarangがChrome Developer’s Toolsに統合されていてデバッグ時にデータを確認しやすい。
• 定型的なコードがかなり減る。
• クラスの再利用がしやすい。
• Backbone.jsに比べて使えるようになるまでが早い。

デメリット

• UIの状態を明示的に（自分が書いたコードによって）変更できない。特に、ng-show属性のエレメントをfede inとかのアニメーションを使って表示させることが出来ない

JavaScriptMVC

メリット

• 実績豊富（IBMで使われている）
• 開発に必要なツールが一通り入ってる。

デメリット

• FWの開発スピードが遅い

CanJS

メリット

• 軽量
• 自動更新テンプレート
• jQuery,Dojoのようなメジャーなライブラリと統合されている
• パフォーマンスがいい
• モデル、ビュー、コントローラ、ルーティング機能がある。
• 大きなアプリが作られた実績はないが、今後作られる可能性はある
• 開発チームが経験豊富

Dojo

メリット

• 様々なwidgetを作れる（画像、グラフ、グリッド）
• JSファイルの遅延ロード機能がある。
• CDNとの統合。
• 国際化機能が強い。
• クラスシステムサポート。
• このFWを土台として新しいFWを作れる。
• シンタックスがシンプル。
• 他のJSファイルを読み込む起点になるローダーファイルの大きさが6KB程度と小さい。
• ビルド機能がある。
• AMDにより依存関係を解決する機能がある。
• DOMの操作からSVG,VML,canvasまで幅広く多くの機能がある。
• ウィジェットシステムのDijitは使いやすさと拡張性が素晴らしい。
• UIコンポーネントがいい。タブ、グリッド、フォームなど。クロスブラウザ対応されている。
• モック（mocks.Integrates）を使って簡単にテストできる。

デメリット

• dojo/_base/declareの機能はstrictモードに100%準拠しているわけではない。後方互換性のためにパフォーマンスが多少犠牲になっている。これらの問題のほとんどはDojo2.0では解決される予定ではある。
• UIコンポーネントのデフォルトのデザインが時代遅れ。
• HTML5対応でない部分がある。
• ドキュメントの量はまずまず。
• テンプレートエンジンは弱い。自動でデータをバインドしてくれない

YUI

メリット

• YUI3は機能がモジュール化されており、必要な機能だけ取り出して他のライブラリと一緒に使える。
• 疎結合化の機能がBackbone.jsより優れている。例えば、イベント関係の機能はイベントモジュールをmixinすることでどのオブジェクトにも追加できるようになっている。
• Ember.jsと連携する機能がある。
• YUIエクステンションが使える。
• モデル、ビュー、ルーティング機能がある。
• 異なるURLを持つ複数のViewを持つアプリを簡単に作れる。
• ビュートランザクションのサポート
• widget、ビューコンポーネント、アーキテクチャ作成をサポートする仕組みを含む全部入りFW

デメリット

• テンプレート作成ツール（yuiproject）はあるが、あまりおすすめできない
• ファイルサイズは大きい
• AMD機能がない。モジュールローダーを使って必要なJSファイルだけダウンロードして使うといったことができない

Spine

メリット

• シンプルで依存するライブラリがない
• 非同期API
• シンプルなモデル、ビュー、コントローラ、イベント、ルーティング
• CoffeeScriptと統合されている
• ドキュメントが豊富

jQuery

メリット

• クロスブラウザ対応
• イベントが使える
• 外部サービスと連携するのに使える
• 拡張可能
• プラグインが豊富

デメリット

• MVCパターンによるコードの構造化はできない
• 複雑なWebアプリを作るのには適さない

Maria

メリット

• ピュアMVCフレームワーク。シンプル。

デメリット

• テストコード、ドキュメントが少ない
• チュートリアルが少ない

Cujo

メリット

• 自分好みのMVCフレームワークが作れる。アプリの要件にフィットしたフレームワークを作るためのローレベルなツールが用意されている。
• プラグインを作るための機能が豊富。プラグインは他のMVCフレームワークを統合したり、拡張したりするのに使える。

デメリット

• コミュニティが小さい。大規模なアプリを作るノウハウが足りない
• ドキュメント、チュートリアル、サンプルが少ない。が、ドキュメントはもうすぐ増えそう。

Batman

メリット

• Viewのバインディングが非常に簡単
• Railsと相性がいい
• CoCを使っていてコードが少なくて済む

デメリット

• ドキュメントが少ない
• 今後開発が順調に進むかが疑問

各FWのGithubでの人気

starとforkの数を調べるプログラムはここで公開しています。

まとめ

・色んなFWについて勉強しよう

沢山のFWについて勉強するのは大変だが、それによって色んなテクニックを知ることが出来る。

沢山のFWに詳しくなると、作るアプリの要件により近いFWを選べるようになる。それによってより実装が楽になる。

・FWをカスタマイズしよう

フレームワークを使っているとそれにしばられがちで、無理矢理フレームワークの部品を使って課題を解決しようとしてしまう。フレームワークを拡張してもっと適切な実装ができないかを考えるべき。

・FWの選定に時間をかけよう

安定で、メンテナンス性の高いアプリを作るために、時間をかけてFWを選ぶことが大事。