Google Closure LibraryフルスペックJSフレームワーク+Templates Kawanet Blog II/ウェブリブログ

Google Closure LibraryフルスペックJSフレームワーク+Templates

<< 作成日時： 2009/11/08 03:10 >>

Google から新しい JavaScript フレームワーク Closure Tools が登場。
まだ試していないけど、ドキュメントを流し読みするだけでも涎が出てくる。
事前コンパイルが基本なので、ブラウザでの実行速度も速そう。
フルスペックだけど、Google各サービスで使われているコードがベースらしいので、
実績もあって安心か？　公開当初から「well-tested」と言い切るほどです。
Closure Tools は、大きく以下の３要素で構成されているらしい。

・Closure Compiler - Python で書かれたコンパイラ
・Closure Library - フルスペックな JavaScript ライブラリ
・Closure Templates - JavaScript/Java 用の HTML テンプレート機構

以下、まず興味をもった部分だけピックアップしてみます。

Closure Templates - Hello World

http://code.google.com/intl/ja-JP/closure/templates/docs/helloworld_js.html

HTMLテンプレートからJavaScriptのソースコードをコンパイルで自動生成する。
画面描画時にテンプレートをパースしないので、高速に表示されそう。

Closure Library - Using the Dependency Calculation Script

http://code.google.com/intl/ja-JP/closure/library/docs/calcdeps.html

goog.require() で他の .js ファイルをロードできる。
これ自体は JSAN や Dojo とかにもあった。
Closure がすごいのは、calcdeps.py で依存を展開してくれるらしい。
-o compiled オプションを付けると、パック(shrinking)もしてくれる。
テンプレートと同様に、事前コンパイルで処理時を高速化する手法か。
ダウンロードされるファイル数も減って、容量も減って、こりゃいいわ。

Closure Compiler

http://closure-compiler.appspot.com/home

Closure Compiler のコンパイル／最適化を試せるページ。AppEngine で動いてる。
コマンドライン版のコンパイラ以外に、Web API も提供されているらしい。
オンラインでパックできる？

Closure Library - graphics.AbstractGraphics

http://closure-library.googlecode.com/svn/trunk/closure/goog/docs/class_goog_graphics_AbstractGraphics.html

このような抽象レイヤが多数提供されて、ブラウザ互換などを実現しているのも
Closure の大きな特徴か。goog.graphics.AbstractGraphics クラスは、
canvas・vml・svg を使う抽象レイヤーらしい。
IE 対応のコードも、１回で書けるのかな！？（動作未確認）
canvas を無理にエミュレートするよりも、専用クラスの方が互換性高そう。

Closure Library - goog.ui.AbstractImagelessRoundedCorner

http://closure-library.googlecode.com/svn/trunk/closure/goog/docs/class_goog_ui_AbstractImagelessRoundedCorner.html

クラクラ、目眩がしそうなほど、甘い香りがするクラス名ですよねですよね？
「画像なし角丸抽象クラス」みたいな、名は体を表す、長い質実剛健な名前が素敵。
ウケるサービスは「角丸重要」ですから、Web エンジニアの夢が実現！？

Closure Library - goog.net.XhrIoPool

http://closure-library.googlecode.com/svn/trunk/closure/goog/docs/class_goog_net_XhrIoPool.html

Gmail は、大量に非同期コネクションを使いまくって便利になったんだと思う。
リソース管理が難しいが、それを調停してくれるクラス、なのかな？
よく読んでないけど、XhrIoPool（XmlHttpRequest IO プール）クラスは、
maxCountでXHRの最大同時接続数を制限できる？のかな。

さいごに

実際の案件でも試してみたいけど、普通なら、枯れているライブラリを使って、
こう登場したばかりのライブラリはバグとか怖いので、利用しずらいけど、
「Google で使われている」となると頑張って使ってみようかな？
という気にさせられてしまいます。仕様変更はあるのかなあ。

しかし、Closure Library のドキュメント（API リファレンス）は、圧巻。
こうなると、玉石混合な jQuery の大量のプラグイン群を探しまわるより、
全部 goog 名前空間（Closure Library）に依存した方が開発も楽！？

Closure Library は、JavaScript における STL／JDK を目指している。
Closure を前提にコードを書くということは、今までの JavaScript でなくて、
別の新しい JavaScript を使って開発する姿勢になるか。
メール(Gmail)も、地図(Maps)も、ブラウザ(Chrome) その他もろもろだけでなく
ついに開発言語も Google 依存になってしまって良いの？（便利なら良いじゃん！）