JavaScriptはいつの間にこんなにでっかくなっちゃったんだろう

はてなブログのニュースに大歓喜しているeller86です。ダイアリーはあちこちガタが来ているように見える（私見）ので、ゼロから書きなおしたというのがとてもプラスに見えています。そのうちバックグラウンドについての技術解説も出るでしょうし、いろいろと楽しみです。

さてここ数日、AMDなどの「JavaScriptのモジュール化」についていくつか眺めていました。なんというか、JavaScriptがこうなるなんて10年前にonclick="hogehoge()"とか書いてた*1頃には想像できなかったなぁという感じです。

• Why Web Modules?
• Why AMD?
• substack/node-browserify · GitHub
• Modules - CommonJS Spec Wiki
• Writing Modular JavaScript With AMD, CommonJS & ES Harmony
• jQuery Blog » jQuery 1.7 Released

これを読み始めたときは

• モジュール化して通信回数が増えたら明らかに遅くなるのになぜそんなことするの？
• 開発中は開発効率を重視するとしても、リリース時はコンパイルして1ファイルにまとめればいいんじゃね？

とか思ってたのですが、RequireJSのサイトにシンプルに

• Assembly gets harder

Why Web Modules?

と書いてあって「ですよねー」と一発KOでした。JavaScriptは各ページごとに特有の処理がある場合が多いでしょうし、ECサイトとかページの種類が多い場合ではなんか現実的ではなさそうですよね。ページによってロード順が違う、結合したら逆に初回ロードが遅すぎて使えない、とかが普通にありそうで。それならモジュール機構でページ固有のスクリプトは分離したほうがいいでしょう。あとjQueryのバージョンAとBとCを1画面で使いたい！的な要望に応えられる可能性があるのも大規模な開発ではいいですね。これをIE6+ compatibleで実装しているRequireJSの凄さを今更にして知りました。

ただ、モジュール化を突き進めすぎて通信回数に悩むというオチが見えるので、ページ固有のスクリプトは1ファイルに絞る、そのうち使うスクリプトは先読みするなどの工夫が必要になりそうですね。特に多数あるスクリプトをどうassembleするのが最適かを考えるのはわりと面白い問題だと思うので、そのうちJavaScript屋さんとグラフ屋さんが結託してフレームワークを作ってくれるんじゃないかと空想しています。でも通信環境が恵まれている今、速度向上の成果がたいして出ない可能性もありそうです。速度という観点からは、スクリプトのプロファイルやAMDの活用法の方が焦点があたっていくかもしれないですね。

*1:小一時間問い詰めたい