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

酔っ払った状態で書くから多少の暴言は勘弁してね。

id:Rockridge さんからコメントをお求められた

Daniel Glazman氏が今のJetpackシンタックスは大嫌いだと言っています。UI拡張性に対する正しいソリューションではないと。
http://www.glazman.org/weblog/dotclear/index.php?post/2010/01/07/Jetpack

teramakoさんのご意見はいかがでしょうか。

XULとの決別、XPCOMの廃止はありえるのか? - hogehoge

ということで書きます。

Daniel Glazman氏の僕の書いたコードへの感想とXULXHTMLとの整合性的な部分について。

Daniel Glazman氏の僕の書いたコードへの感想

the first winner's code is absolutely not understandable to even an advanced XHTML+CSS developer. Reading Cc["@mozilla.org/appshell/window-mediator;1"].getService(Ci.nsIWindowMediator).getMostRecentWindow("navigator:browser"); in some code that is supposed to be simpler than XUL+chromeJS is puzzling, to say the least...

Jetpack and making the UI world adopt HTML5 - &tl;Glazblog/>

はい、その通りです。僕の書いたコードは一般人には理解できないコードでしょう。
こんなコードは公的に認められるべきではないのです。だからこそ、僕は前エントリコーヒー飲んでいる時だったら間違いなく噴いたね。正直ネタとしてエントリしただけで入賞なんて全然狙ってなかった。と書いたのです。
一点言わせてもらうと僕の書いたjetpack feature installerは開発者向けに作ったのであって一般ユーザ向けには作っていないということです。現状のJetpackでは開発し難いぞっという批判と皮肉を込めたコードで、今後もこんなのが許されるの? というアンチテーゼを込めたつもりでした。それが受賞してしまったのですから、驚きです。

ただし、ここ一週間ほどの期間でまた思いが変わってきたことは確かです。
一つはFirefoxアドオンはJetpackへ、ユーザに波紋 | エンタープライズ | マイコミジャーナル

最初にMozillaが既存のアドオンの仕組みは捨てないとはっきり明言しているので、少しほっとしました。

アドオンで再起動がいらなくなるかもしれない - すめるまん Broken Diary

で旧来のXUL+XPCOM+JavaScriptが完全には否定されていない点です。やはり、MozillaXULXPCOMを捨てきれないみたいだ、という点は僕にとって多少の慰めとなりました。せっかく受賞したのですから、正当な評価の表れだと少し思うようになりました(この部分自分自身への慰めであって読者が共感する必要はないですので注意)。

ただ、やはりJetpackのコードにXPConnectを使うのは場違いであることは確かだと思います。その点でDaniel Glazman氏のいうことに賛同します。JetpackJavaScript+jQeury+jetpackAPIで構成されるべきでしょう。そこにXPConnectXULを使用するのはイレギュラーだと思います。

う〜ん、やっぱり僕自身気持ちの整理がついていないのか、矛盾したことを書いているかも。

Daniel Glazman氏のXULXHTMLとの整合性的な部分について

I also think the integration of XHTML elements inside a XUL-based UI raises strong UI homogeneity issues (because they don't flex, align or pack like XUL elements) and could severely harm the UI coolness factor of the whole user interface.

Jetpack and making the UI world adopt HTML5 - <Glazblog/>

ちょい簡単に訳すと(間違いがあったらご指摘を。稚拙なのはご勘弁を)

また、XULベースのUIとXHTML要素の統合はUIの調和において酷い問題を起こし(なぜなら、XHTMLXUL要素のようには伸縮しないし、整列 や一塊にはならないから(この辺り真っ当は訳を求む))、ユーザインターフェイス全体の落ち着きを激しく損なうと思う。

って感じでしょうか。

彼の言っていることは、 id:Gemma さんのhttp://www.geocities.jp/teruakigemma/modest/presen091219.html;title=プレゼン資料XUL自動レイアウト(動画)が分り易いと思う。この動画のUIはスクリプトCSSもほとんどなしのXULのみで実現でき、HTMLとは違う伸縮性を持っていることが分かる。
この違いがHTMLでUIを記述したときに違和感なって現れてくると思います。

また、OSのGUIとの整合性という観点で見たとき、HTMLは欠点になるでしょう。
Gemmaさんのプレゼン資料の一部からも分かりますが、例えば yes/no を問うダイアログを考えてみましょう。Windowsでは左側にOKボタン、右側にキャンセルボタンとなるでしょう。他のプラットフォームでは場合によっては左にキャンセル、右にOKとなります。これをHTMLで記述するとどのプラットフォームでも同じ表示となり、そのOS*1デフォルトの挙動と異なる表示になるのです。それが良いことなのか悪いことなのか僕には分かりませんが、(OS的な観点から見て)統一感がないという思いは拭えないでしょう。

Jetpackの将来

彼の話に戻ます。
彼の主張は、Jetpackには2つの目標があって

  1. アドオンシステムをXUL開発者だけでなくWeb開発者にも発展させる
  2. HTML5/JS/CSSを汎用的かつ一般的なUI言語としての道を切り開く

1はまだ明らかに達成されていない。このままではXULと同様JetpackMozillaのみののものとなってしまうから2は別の道を辿る必要がある(W3Cとの連携を示唆しているのかな? 良く分からない)。とりあえず、拡張は全てのブラウザで動くように各ベンダーと協力すべきって感じだと思う。

特に後者は僕にとって衝撃というか目から鱗でした。素晴らしい目標だと思いますが、はたして可能なのかという疑念が付きまとっている。現状のHTMLでUI定義は不向きだと思う反面、別言語にしたらWeb開発者の参入が難しくなるでしょう。

ともかく、Jetpackは将来に関してもっともっと議論すべきだってのには賛同します。

今思っているのはこんな感じ。id:Rockridge さんこんなので回答になっているでしょうか・・・。

*1:ウィンドウマネージャと言った方が正しいかも