MVCフレームワーク」がいくつも登場し、注目され始めています。MVCフレームワークがテーマとなり、主なフレームワークの紹介と座談会が行われました。それぞれのフレームワークがどんな特徴を持ち、何に向いているのか。非常に勉強になる内容でしたので、この記事では座談会の内容を紹介したいと思います。座談会に登壇したのは以下の方々です。北村英志氏(グーグル)司会はPublickey新野が務めました。司会を仰せつかった新野です。座談会の前半は主に技術的な部分について聞いてみたいと思います。「ぶっちゃけ、遅くなったり重くなったりしなんですか?」とか、「UIバインドがあるフレームワークとないフレームワークって、どっちがどういいの?」とか、「jQueryと混在して使うとすると、相性などはあるの?」「クライアント側のMVCのモデルをサーバ側に保存するときはどうするんですか」などです。それから少しフレームワーク周辺の話題として、学習のしやすさはどうか、とか、ドキュメントやコミュニティ関連の状況についてもお伺いしていきたいと思います。フレームワークを使うときには「遅くなるんじゃないか」といった心配は多くの人が感じると思うので、そのあたりどうなのか。Backbone.jsの清水さんから、教えてください。Backbone.jsを使って遅くなったと感じたことは、はっきりいってないですね。軽量なフレームワークなので、著しく遅くなるとかそういったことを感じたことはなかったです。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フレームワーク導入による)生産性を考えれば十分に使う意味はあると思います。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の拡張機能です。自分のプロジェクトを一覧する機能で、これはサーチ機能がなかったんです。いうのもサーチは作るのが面倒くさかった。AngularJSでは2~3行のコード追加だけで、1文字ずつ打つだけでどんどん絞り込めるフィルター機能が書ける。これだけでもAngularを使ってよかったなあと思いました。現在は多くのJavaScriptプログラマがjQueryやほかのライブラリを使っていると思います。いったライブラリとの組み合わせや依存関係はどうなんでしょうか。Backbone.jsはjQueryかZeptoをDOMの操作に使うようになっています。jQueryはZeptoに比べると重たいという話があって、Zeptoはそれを解決するために軽量なフレームワークになっています。テンプレートエンジンはHandlebarsなど何でも使えます。SpineはBackbone.jsとほぼ同じで、jQueryかZeptoを使った方がいいでしょうと。Templatesでも何でも使えて、相性問題もないかなと思います。Ember.jsの方は、(jQueryなどが)なくても一応使えるのですが、ほとんどのアプリケーションがjQueryにほぼ依存しているような形になっています。いうのも、Ajaxでデータを取得したりするメソッドがEmber.jsにはないので、そのために依存していると。軽量なものを使うことで代替できるのであれば問題ないですが、基本はjQueryと一緒に使うのが標準です。AngularJSは、実は内部にjqLiteというjQuery互換ライブラリを持っています。自分たちで互換ライブラリを作ったようです。jQueryがあればそれをオーバーライドするようにもなっているので、必要であればフル機能のjQueryも使えます。後編では、モデルをサーバサイドに送る話、学習曲線について、そして会場からの質問などを紹介します。MVCPublickey広告.NET帳票ツール。デザイナはExcel。クラウド/サーバー環境対応。.NET5/6/8に対応。デザイナはExcelのため、エンドユーザーも編集可能。ノーコードでCSVファイルから帳票を出力する、CSVReportも新収録。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Copilotが複数ファイルにわたるコード変更や生成に対応。CopilotがAppleのXcodeに対応。Xcode」パブリックプレビューOrbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に[PR]日本人プログラマ向け、プログラミングに適した「フォント」まとめ。2024年版GitHubで最も使われている言語、PythonがJavaScriptを抜いて1位に。生成AI関連プロジェクト急増で。Sonnetが選択可能に。100」の仮想マシンを正式提供開始JetBrains、JavaScript/TypeScriptのためのIDE「WebStorm」と.NETのためのIDE「Rider」、非商用利用ならば無償で利用可能に。