JavaScript MVC座談会。遅くならない? それぞれの特徴は? サーバとの通信は?(前編)

2012年7月17日

JavaScriptでの大規模アプリケーション開発を支援する「JavaScript MVCフレームワーク」がいくつも登場し、注目され始めています。7月11日に開催された「第31回 HTML5とか勉強会」では、このJavaScript MVCフレームワークがテーマとなり、主なフレームワークの紹介と座談会が行われました。

それぞれのフレームワークがどんな特徴を持ち、何に向いているのか。非常に勉強になる内容でしたので、この記事では座談会の内容を紹介したいと思います。

座談会に登壇したのは以下の方々です。

Backbone.js 清水大輔氏(NHN Japan)
Spine 村田賢一郎氏(Acroquest Technology)
Ember.js 斉藤祐也氏(サイバーエージェント)
AngularJS 北村英志氏(グーグル)

司会はPublickey新野が務めました。

fig 写真左から新野、清水氏、村田氏、斉藤氏、北村氏

JavaScript MVCフレームワーク座談会

新野 司会を仰せつかった新野です。座談会の前半は主に技術的な部分について聞いてみたいと思います。例えば、「ぶっちゃけ、遅くなったり重くなったりしなんですか?」とか、「UIバインドがあるフレームワークとないフレームワークって、どっちがどういいの?」とか、「jQueryと混在して使うとすると、相性などはあるの?」「クライアント側のMVCのモデルをサーバ側に保存するときはどうするんですか」などです。

それから少しフレームワーク周辺の話題として、学習のしやすさはどうか、とか、ドキュメントやコミュニティ関連の状況についてもお伺いしていきたいと思います。

では最初の話題。

やはりフレームワークを使うときには「遅くなるんじゃないか」といった心配は多くの人が感じると思うので、そのあたりどうなのか。まずBackbone.jsの清水さんから、教えてください。

清水 はい。Backbone.jsを使って遅くなったと感じたことは、はっきりいってないですね。軽量なフレームワークなので、著しく遅くなるとかそういったことを感じたことはなかったです。

村田  Spineも小さいフレームワークなので、遅くなると感じたことはなかったですし、SpineのコンセプトとしてAsynchronous UI(非同期UI)というのがありまして、要するにクライアントサイドでデータを保持して、非同期でサーバサイドと通信することでユーザー体験を速くすると。ですので、使うとむしろ速くなるという点は、どのフレームワークでも共通して恩恵を受けられるところかなと思います。

新野 お二人からは「遅くなることはない」というご発言でしたが、逆にこんな使い方をすると遅くなってしまう、というアンチパターンみたいなものはありますか?

清水 そうですね。Backbone.jsもSpineも同じような書き方なのですが、基本的にdelegeteを使う書き方なんですね。それを守らないで1つ1つのDOMにイベントをアタッチすると、遅くなるのかなと。

新野 ありがとうございます。では質問を戻して、Ember.jsで「遅くなったりしないのか?」について斉藤さん。

斉藤 Backbone.jsやSpineと違って、Ember.jsは42kb。MinifyしてGzipしてそれくらいあるので、小さいアプリケーションでEmber.jsを使うのは疑問があると思います。けれど、大規模なプロジェクトではEmber.jsなしでいくつもJavaScriptのファイルができてエラいことになって管理ができない、ということになるよりは、Ember.jsを使ってMVCを使って作る方が、スピードという点では速くなるかなと思います。

新野 重くなるというのは、フレームワークがボトルネックになって遅くなるのではなく、フレームワークの大きさがメモリなどを圧迫して重くなる要因になる、という理解でよいのでしょうか。

斉藤 そうですね。フレームワークを使うことで重くなるということはなくって、(Ember.jsで使われているテンプレートエンジンの)Handlebarsは高速なレンダリングエンジンといわれているので、スピード自体は速いのですが、やはり42kbというのは決して身軽ではないというところですかね。

北村 AngularJSはまだ一週間くらいしか触っていないのですが、勉強のために自分のプロジェクトをAngularJSで書き直してみたんですね。やってみて、ぶっちゃけ75kbで、ちょっと遅くなりました(笑)(座談会後の北村氏からの補足情報として、AngularJSはMinify+Gzipで29kbになるとのこと)。

ただ、使えないレベルで遅くなることは当然ありませんし、(MVCフレームワーク導入による)生産性を考えれば十分に使う意味はあると思います。

UIバインディングがあるのがいいか、ないのがいいか

新野 やはりAngularJSとEmber.jsは、より生産性を重視するところがある、ということですね。

そのAngularJSとEmber.jsは「UIバインディング」、つまりモデルのデータを変えると自動的にビューまで変わるという機能を含んでいます。一方の、SpineとBackbone.jsはそれを含まないシンプルなフレームワークになっています。

これはそれぞれいいところ、そうでないところがあると思うのですが、まずAngularJSとEmber.jsで、UIバインディングがあるのはこんなにいい、というお話をしていただいて、そのあとSpineとBackbone.jsで、いやいや、UIバインディングがない方がいいんだ、というお話をしていただけないでしょうか。

北村 そうですね。UIバインディングができるとコードの量が相当減らせる、というのが大きいかなと。それから直感的にいじれる、生産性が上がるという点はあると思います。

斉藤 僕もかぶるところなんですが、データをいじって、それが自動的にDOMに反映されるというところは、どのみち発生する作業なのかなと思っているので、どこかの誰かが作ったUIバインディングにこだわりがなければ、Ember.jsであれAngularJSであれ便利に使るのではないかと思います。

新野 逆にUIバインディングがないフレームワークのいいところを教えてください。

村田 やはりビューの部分に、自分の好きなライブラリや使いたいフレームワークがあるというのが私の前提なので、そこを細かく制御できるというのがいいところかなと思います。

それから、ビューにどうやって反映しているのか分かる。もちろんそこのコードを自分で書いているということはあるのですが、だから分かりやすい、というのはあると思います。

清水 自動のUIバインディングがあればたしかに生産性が高くコードを減らせる点ではいいと思うのですが、かゆいところに手が届かないというか、細かいことをやろうとしたら結局自分で書いた方が早いかなと、Backbone.jsやSpineはそういうところが利点かなと思っています。

北村 さっきちょっとお見せできなかったんですが、リストがあったときにそれがフィルタリングする機能、リストを絞り込むをJavaScriptを書くのはすごくしんどいんです。それが、AngularJSだと簡単に書けます。

この例は、私がJavaScriptとAnglar.jsを使って作ったChromeの拡張機能です。自分のプロジェクトを一覧する機能で、これはサーチ機能がなかったんです。というのもサーチは作るのが面倒くさかった。

fig

でも、AngularJSでは2~3行のコード追加だけで、1文字ずつ打つだけでどんどん絞り込めるフィルター機能が書ける。これだけでもAngularを使ってよかったなあと思いました。

jQueryやほかのライブラリとの共存は?

新野 現在は多くのJavaScriptプログラマがjQueryやほかのライブラリを使っていると思います。そういったライブラリとの組み合わせや依存関係はどうなんでしょうか。

清水 Backbone.jsはjQueryかZeptoをDOMの操作に使うようになっています。jQueryはZeptoに比べると重たいという話があって、Zeptoはそれを解決するために軽量なフレームワークになっています。テンプレートエンジンはHandlebarsなど何でも使えます。

村田 SpineはBackbone.jsとほぼ同じで、jQueryかZeptoを使った方がいいでしょうと。ビューの方も何でもいいので、Handlebarsでも、jQuery Templatesでも何でも使えて、相性問題もないかなと思います。

斉藤 Ember.jsの方は、(jQueryなどが)なくても一応使えるのですが、ほとんどのアプリケーションがjQueryにほぼ依存しているような形になっています。というのも、Ajaxでデータを取得したりするメソッドがEmber.jsにはないので、そのために依存していると。もちろん、もっと軽量なものを使うことで代替できるのであれば問題ないですが、基本はjQueryと一緒に使うのが標準です。

北村 AngularJSは、実は内部にjqLiteというjQuery互換ライブラリを持っています。多分自分たちで互換ライブラリを作ったようです。

jQueryがあればそれをオーバーライドするようにもなっているので、必要であればフル機能のjQueryも使えます。

後編に続きます。後編では、モデルをサーバサイドに送る話、学習曲線について、そして会場からの質問などを紹介します。

JavaScript MVCフレームワーク関連記事

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : JavaScript , MVC



≫次の記事
JavaScript MVC座談会。遅くならない? それぞれの特徴は? サーバとの通信は?(後編)
≪前の記事
Google Compute Engineはエンタープライズ市場でどれだけ戦えるか?

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus