最近では LABjs, Underscore.js, Backbone.js といった JavaScript フレームワークが注目を集めています. これらに共通する特徴はあるひとつの問題を解決するためのシンプルで小さなフレームワークであるということです.

このような "小さな" フレームワークと jQuery や Prototype のような "フルスタック" なフレームワークに関して, 面白い議論がなされていました.

マイクロフレームワーク

話は script.aculo.us の作者であり, Prototype のコア開発者である Thomas Fuchs さんのブログから始まります.

mir.aculo.us JavaScript with Thomas Fuchs » Blog Archive » I for one welcome our new micro-framework overlords

まずここで述べられているマイクロフレームワークとは以下のようなものです.

• 単一の問題を解決するためのフレームワーク
• 小サイズ
• pure JavaScript で書かれ, 他のフレームワークに依存しない

そして Fuchs さんは以下の理由で JavaScript のフレームワークは単一の問題を解く小さいものであるべきだと主張しています.

• フルスタックのフレームワークの場合, 必ずしもすべての機能が必要なわけではない
• サイズが大きくなり (100+ KB を超える) クライアントが接続するたびに毎回このサイズのファイル転送が発生する
• マイクロフレームワークならば,
  • 必要なものだけを選択し組み合わせることができる
    • 同じ問題に対するフレームワークの中からベストなものを選択できる
  • コード量が少なければバグも少ない
  • 他ライブラリに依存せず, スタンドアローンで動作する
    • jQuery プラグインはこの点でよくない

フルスタックフレームワーク

Tom Dale さんはこのエントリに反論しています.

Imagine a Beowulf Cluster of JavaScript Frameworks - tomdale.net

現在の複雑化している Web Application の開発のためには, フルスタックなフレームワークが適していると主張しています. マイクロフレームワークの問題点として以下が挙げられています

• Dependency hell
• 開発者は大量の選択肢を検討しなければならない
  • 実際には happy path が求められることが多い
• フレームワークを小サイズにおさえても, その不足を埋めるためアプリケーション側のコードが大きくなることが多い
  • 同じコードがフレームワーク・アプリケーションに存在し得るならば, コミュニティによりよくテスト・最適化されるフレームワーク側にあったほうが良い
  • 例えば NewTwitter の js は 1MB を越えている
  • それだけ Web Application が複雑になってきている. それだけの大きさのコードを自分でテスト・最適化するのは大変な手間

Ender.js

Ender.js は両エントリで (割と好意的に) 取り上げられていたフレームワークです.

Service Unavailable

Ender.js はその各機能 (Selector, DOM Utility, Event, Classes, etc...) を npm パッケージの中から選択しビルドできるというフレームワークです. デフォルトでは qwery, bean, bonzo, klass, reqwest, emile, scriptjs, domready, underscore が含まれるそうです. 不要な機能はもちろん外すこともできます.

まとめ

小さなフレームワークとフルスタックのフレームワークのメリット・デメリットについての議論を見てきました.

結局のところ "適材適所" というありきたりな結論にたどり着いてしまいそうです. 大規模なプロジェクトならば重厚なフレームワークを採用するし, そうでないならば軽量なフレームワークが選択されるでしょう. 他の言語を思い返してみるとそれは当然な気がします.

Unix のように共通のインタフェースさえ確立出来れば, "一つのことをうまくやる" フレームワークがありそれを組み合わせるモデルがうまくいく気もします. そういう意味では Ender.js などの動向は注目していきたいところです.