Re: "Jetpack and making the UI world adopt HTML5"について

id:teramakoさん、質問に対する丁寧なお返事ありがとうございました。興味深く拝読しました。また、XUL＋XPCOM＋JavaScript（以下この組み合わせをXXJと略）に対する複雑な思いが伝わってきました。

Jetpackが現実解

私が最初に投げかけた質問に絡めて、「HTML5/JS/CSSを汎用的かつ一般的なUI言語」とすることに関し、teramakoさんは、「はたして可能なのかという疑念が付きまとっている」とお書きになっています。私も考えてみたのですが、やはりHTML5＋JavaScript＋CSSをXXJの代わりにするのは無理でしょう。もともとWebブラウザのUIを制御するための仕様ではないのですから。

かといって、W3Cを通じて、XULのようなインターフェイス言語を新たに作るのは、コストがかかりすぎます。日進月歩のWebから取り残されるのは目に見えています。今は、Internet Explorerが圧倒的なシェアの上に胡座をかいていてくれた時代とは明らかに状況が違います。

そうであれば、Jetpackの方式が現実的です。私の理解では、JetpackはUIの要素を抽象化し、その抽象化された要素に対する制御方法を提供しているようですが（例：SlideBar）、抽象化の内容や制御方法を工夫することで、UIの細部をコントロールできないとの不満を解消したり、他のWebブラウザ（とくにGoogle Chrome）とAPIの互換性をもたせたりすることはできないものでしょうか。

Mozillaは、明らかにJetpackに重きを置くようになりつつあります。そう遠くない将来、Jetpack APIs＋Library＋JavaScriptがXXJに比べて優勢となり、Jetpack Featureが主、従来の拡張機能が従となるでしょう。もちろん、Mozillaの中も一枚岩ではありません。Mozilla Add-ons（AMO）は『Add-ons are here to stay』の中で、予想される限りの将来において、XULベースのアドオンがなくなることはないとしていますが、Jetpackの開発チームは、『The Future of Add-ons』の中で、Jetpackが現行のシステムと同程度に機能的かつパワフルになったときは、全拡張機能を新プラットフォームに移行させることが妥当かどうかを話し合うことになるとしています。

ただ、AMOもJetpackの優位を否定するものではない点に注意が必要です。このように、Jetpackの進化が約束されている以上、Daniel Glazman氏のように理想のUI言語を提唱するよりは、よりよいJetpack APIを提案するほうが有効かもしれません。

高機能とセキュリティの両立

Jetpackはいかにして既存のXXJに勝る実力を備えていくのでしょうか。そのヒントは『Evolving the Firefox Add-on Platform』にあると思います。実は、Jetpackはrebootと呼ばれる再構築を控えているのです。新システムでは、CommonJS標準ライブラリが使用され、Jetpack FeatureをXPIパッケージとして提供できるようになるといいます。

teramakoさんが早くから懸念されていらっしゃったセキュリティの問題も、新しいモデルによって解決を図ります。Jetpack Featureはサンドボックスの中で動作し（マルチプロセスにも対応）、Principle of Least Authority（最小権限の原則）に従うので、通常はjQeuryなどの安全なライブラリだけを呼び出すことになります。

しかし、Superpowerと呼ばれる、より強力なライブラリも提供される予定です。Jetpack Featureは、このSuperpowerを通じて、Mozillaプラットフォーム本体、ひいてはXPCOMやXULにアクセスできるのです。逆に言えば、このメカニズムを使うことを強制されます。したがって、「JetpackのコードにXPConnectを使うのは場違いである」というだけにとどまらず、今後は禁止されるでしょう。

Superpowerは、Jetpackのランタイムに包摂されます。ちなみに、Jetpack FeatureとSuperpowerがコミュニケートする際は、membrane（細胞膜）と呼ばれるラッパーが用いられるそうです。

それでも従来のアドオンは残る

Jetpackが再構築され、次第に強化されていくとして、従来のXXJ扱いも気になるところです。上に述べたとおり、Jetpackの開発チームはけっこう冷淡で、徐々にフェードアウトしてもらっても構わないとのスタンス。昨年11月に作成された予備的なロードマップでもそうなっています。なお、ロードマップの右端には、さりげなく、APIの標準化を探るとの記載があります。

しかし、Firefoxというプラットフォームに密接に統合され、そのポテンシャルを汲み尽くすようなアドオンを作ろうと思えば、今後もXXJをベースにせざるを得ません。問題は、開発者にそうした手の込んだアドオンを作るインセンティブがあるかですが、Webユーザーの4分の1が利用するプラットフォームで有名なアプリケーションを作りたいという人はきっといるでしょう。

また、AMOが課金システムを整備していけば、作者が生活の足しになるだけの収入を得られる可能性もあります。もちろん、シェアウェアのような機能制限はかけられないでしょうが、マイクロペイメントがもっと手軽にできれば、気軽に寄付しようと考えるユーザーは、少なくないはず。この条件はJetpack Featureも同じですが、お金が取れるくらい優れた、オリジナリティのあるアドオンは、お仕着せのシステムからではなく、高度な知識と技量の中から生み出されるのではないでしょうか。