XULとの決別、XPCOMの廃止はありえるのか？

Mozilla Firefox Jetpack

おめでとうございます！　http://bit.ly/5zueJf　
RT @teramako: そいえば、 #jetpack 50 line contest はどうなったんだ?

Twitter / Gen Kanai: おめでとうございます！　http://bit.ly/ ...

コーヒー飲んでいる時だったら間違いなく噴いたね。

正直ネタとしてエントリしただけで入賞なんて全然狙ってなかった。

理由としてはエントリのために多少の変更を加えたものの
id:piro_or さんが指摘されている

.@teramako 受賞作3作のうち1つはXPConnect使用、1つはraw使用……憂慮すべき事態ですよこれは。言っちゃ悪いけど、これらを選出してしまうという事が、XULとの決別とかXPCOMの廃止とかをやる気がMozillaに全くない事の証明になってしまってる。

Twitter / Piro: .@teramako 受賞作3作のうち1つはXPCo ...

この点が大きく、僕がエントリしたものはComponentsやXPConnectを使っているという点で審査の対象外だと思っていたからだ。僕の作ったやつは将来にわたって使える保証は全くない、というか、将来的に使えなくなることが望ましいものだ。少なくともXPConnectは使えなくなるのが望ましい。

まぁそれはともかく、XULとの決別とかXPCOMの廃止は気がかりだ。
Mozillaがこれを検討していることの狙いはパフォーマンスにあるんじゃないかと思っている。
Firefox含めMozilla製品はXUL+XPCOM+JavaScriptで作られている。Firefox等の製品はそのほとんどが拡張機能と同質のXULと呼ばれるXMLでUIが定義され、動作がJavaScriptで書かれている。Firefox,Thunderbird,Sunbird,Prism,etc...はコアとなるXULRunnerに拡張機能を追加してその製品となっている、といっても過言ではない。

最近聞かれるFirefoxのパフォーマンスの悪さは、この２つのテキストを介すものだと思う。バイナリのネイティブと比べればパフォーマンスはかなり劣るはずだ。この２つがあるからこそ、容易で柔軟な拡張性が生まれるわけだが・・・(言っておくがFirefoxの拡張性はGoogleChromeの比ではない)。
Firefoxから拡張性を取ったら何が残るというのだ。パフォーマンスを追求して拡張性を失わせるということはGoogleChromeと同じ土俵に立って戦うことになるわけで、「ブラウザ選択の時代」として全然面白くない。速いが正義のGoogleChromeと拡張性が正義のFirefoxと異なる土俵で戦うから面白いのに。
さらに、XUL、XPCOMがなくなるということは、今使えている拡張機能のほとんどが使えなくなるということになる。今まで気付き上げてきた多様な拡張機能を全て捨てるに等しい。

そんなのが許されの？ というかそんな選択をMozillaはするのだろうか？

一般的にはGoogleChrome程度の拡張性があれば事足りる、という意見があると思う。数多あるFirefox拡張もGoogleChrome拡張に置き換えられるものも多い。速さで勝るGoogleChromeにシェアを奪われFirefoxは少数のGeekの玩具になってしまうだろう。

その点を考えるとXULとの決別とかXPCOMの廃止も分からんではない・・・のだが・・・でも、でも、でも・・・

とまぁこんな感じで id:piro_or さんの言を受けて悶え苦しんだ一日であった。