Killer Application
tetsuya_odaka
Killer Applicationという言葉がある。特定の分野内で「他のアプリケーションを葬り去ってしまうほど際立ったアプリケーション」という意味。そして、これが大勢の人に認知されると、デファクト・スタンダードと呼ばれるようになる。
OSSの世界では、EclipseやStrutsなどがよい例だと思う。
半年以上、Ajax関連のJavaScriptライブラリーの優劣を決めようと思ってきたが、最近では、「この分野にKiller Applicationは(まだ)存在しない」と考えるようになった。
言葉を変えれば、ライブラリーそれぞれに持ち味がある、ということ。また、寡占状態にも陥っていない。
さて、この状況でとりうる選択は何か?
「ケースバイケースで使い分ける」というのも一つの選択肢だろうが、これではコストがかかりすぎる。「主だったライブラリーを使って、いいとこ取りで汎用モジュールを作る」というのも一つの選択肢。再利用性という言葉的には良さそうに聞こえる。モジュール開発をすれば、全体のコストも下がるだろう。だが、ライブラリーは決して小さいものばかりではないから、通信コストがかかってしまう。日本ではナローバンドの環境がなくなってきたが、グローバルにはまだまだナローバンドの地域の方が圧倒的に多い。それ以前に、ライブラリーをロードするのに5秒もかかってしまっては、ユーザビリティー的にこのましくない。
有名なAjaxライブラリーと呼ばれるライブラリーには、XHR(XMLHttpRequest;非同期通信)モジュールとEffectモジュールが含まれるのが一般的である。また、これらのコアとしてのDOM操作、イベント操作のモジュールが含まれる。
AjaxはAsynchronous Javascript and XMLの略であるから、言葉としてはXHRを指す。
現在の到達点は、
- Ajaxライブラリーの本質は(字義通り)XHRであるということ。
- コアの価値は高いということ。
- 普遍的Effectは少数であるということ。
- 見た目のよいEffectが必ずしもユーザビリティーを高めるものではないということ(一時的なユーザーエクスペリエンスとしてのインパクトはあるかもしれない)。
- Ajaxライブラリーだけで完全なユーザーインターフェイスは作れず(これは当たり前)、補完するためのコード量が膨大なものになってしまうこと。
ということ。
こう考えると、数あるAjaxライブラリーの「差別化要因」の殆ど全てが排除されてしまう。だが、逆に「どのライブラリーをつかっても、用意したモジュールの(特定ライブラリーへの)依存性を低く抑えられる」ともいえる。
どうやら、自分の考え方がまとまってきたようだ。