Firefox、XUL/XBL技術を捨てる方向へ？ 25
ストーリー by hylom
いまとなっては大きすぎるのかも 部門より
いまとなっては大きすぎるのかも 部門より
insiderman 曰く、
Firefoxの開発者らが、Firefoxで使われているXULやXBLといった技術について、今後これらの利用を止める方向で検討を進めているという（Phoronix）。
XUL/XBLはマルチプラットフォームに対応するライブラリで、ユーザーインターフェイスの構築や各種ネットワーク通信などの機能を備えている。現在は議論の初期の段階であり、これによってどのような影響が出るのかについてはまだ分からないとされているが、Mozillaでは現在Rust言語で実装された「Servo」というレンダリングエンジンの開発を進めており、またUIをHTMLで実装する実験なども行っている。少なくともそう遠くないうちにFirefoxの何かが大きく変わることは間違いなさそうだ。
捨てるべきはXPCOMであって、XULではないのに… (スコア:3, 興味深い)
XPCOMはAPIの古さから、そろそろ捨ててほしいです。逆にXULは、Windowsのピクセル依存UIやHTML/CSSの制限を無視して作られたため、当時のUI言語としてはピカイチでした。
HTMLのサブセットという扱いでも良いので、XULを生かす方法は無いのでしょうか…
http://www.ibm.com/developerworks/jp/webservices/library/co-xpcom.html [ibm.com]
>XPCOMは、確かにスレッドをサポートしています。ただし、スレッド・セーフなコンポーネントは標準的なものではなく、むしろ例外的です。
>ほとんどのコンポーネントは、メイン・アプリケーションと同じスレッド内に共存するように記述されるからです。
Re: (スコア:0)
古いって捨てる理由になるの？
Re:捨てるべきはXPCOMであって、XULではないのに… (スコア:1)
古いってのは時間が経ったという意味ではなく、捨てるべき時が来たってことじゃないのかな。
Re: (スコア:0)
既にjs-ctypesというものがあるので、XPCOMは要らない気がします。
安定したAPIなんて幻想。
Re: (スコア:0)
原理主義者にはアンチパターンってだけで十分かと。
Re: (スコア:0)
捨てる理由としては十分だと思うけど。
Re: (スコア:0)
Fx40でXPCOMはサポート切れますよー
https://www.mozilla.org/en-US/firefox/40.0beta/releasenotes/ [mozilla.org]
Re:捨てるべきはXPCOMであって、XULではないのに… (スコア:2, 参考になる)
> Removed support for binary XPCOM components in extensions, use addon SDK "system/child_process" pipe mechanism for native binaries instead
正確にはこうですよね？間を省き過ぎ。
Fx40で（、拡張機能内で使用される、バイナリの）XPCOMはサポート切れますよー
Firefox というブランド名だけ残したいということ？ (スコア:2, 興味深い)
Mozillaの超高速レンダリングエンジン「Servo」の実力とは? | マイナビニュース [mynavi.jp]
なるほど新レンダリングエンジンを採用した暁には、Gecko [mozilla.org] が利用している XUL/XBL も葬ってしまうことも考えているのか。でもそうしたら Firefox にはあと何が残るの？
モデレータは基本役立たずなの気にしてないよ
キツネですから (スコア:1)
古く枯れた技術も重要ですが、その時点で考えうる最善の技術を提供する。
そういう戦略はアリでしょう。
そもそもキツネの姿をしたトカゲだったわけで、化かされてあげましょうよ。
Re:キツネですから (スコア:2)
細かい事だけど、恐竜まがいの何かから、火の鳥が分化したけど、同じ名前の別の何かが既に居た、って事が2度も有ったんで、最終的に狐に化けたんじゃなかったっけ??
Re: (スコア:0)
RDBMSのfirebirdが前からあったのでゴメンした結果がfirefox
であってるでしょうか
Re: (スコア:0)
firefoxの直接の先祖はフォニックスです
Re: (スコア:0)
Netscape Communicatorからメールなどの機能を捨て去って、旧Navigatorの再デザインを行った時の名前はPhoenixですね。この時点ではプロジェクト名と製品名に区別がなかったので、いずれにしろPhoenixです。
http://website-archive.mozilla.org/www.mozilla.org/firefox_releasenote... [mozilla.org]
ちなみに、FirefoxとFirebirdは(Mozillaではなく)Phoenixのバージョンナンバーを引き継いでいるの
Re: (スコア:0)
外野としてはPhoenixの頃がとても楽しかったな。
可能性を感じるプロダクトが成長していく様はとてもわくわくする。
ある程度の成功を収めてしまうと、それ以上の飛翔はさほど望めなくなり退屈に至る。
Re: (スコア:0)
一エンドユーザとしては、退屈なくらい枯れて安定しているのが一番ありがたい。
Re: (スコア:0)
Firebird の前に Phoenix って時代があって、その時もごめんなさいしてるんだけどね。
Re:Firefox というブランド名だけ残したいということ？ (スコア:1)
何が残るって、XULがHTML5に置き換わることで何が無くなるんでしょうか？
Firefox(正確には前身のMozilla Suite)が設計された当初は独自規格のXULを作らなければ他に方法がありませんでしたが、HTML5が完成した今、UIの記述にXULを使い続ける意味ってなんなのでしょうか。
エンジンを刷新するタイミングでUIをXULからHTML5に変更するならおかしな話ではないと思いますけど。
Re:Firefox というブランド名だけ残したいということ？ (スコア:2, 興味深い)
既存の拡張機能が使えなくなるのならばFirefoxを使う理由がなくなると思います。
HTML5で表現力が上がったといっても、
XULで用意されているUIコンポーネントを全部HTML5で同等品を作るのは正直面倒なのです。
（既製品のものとXULと完全互換のものをHTML5であらかじめ用意してくれるのなら別）
Re:Firefox というブランド名だけ残したいということ？ (スコア:4, 参考になる)
元記事のネタ元であるDave Campのメール [mozilla.org]ぐらい読もうよ。
その辺りの議論は全て述べられているから。
簡単に要約すると、
・XULが作られたのは当時のHTMLが貧弱だったからだが、今では逆転している。
・XULは実効速度に問題がある。
・XULのせいでレンダリングエンジンが複雑化している。
・しかし、既存の拡張機能をどうするかの問題がある。
・XULの代わりに何を使うのかも考える必要がある（HTML5だとは言っていない）。
・XULの置き換え以前に、まだまだやることがある。
Re: (スコア:0)
元コメの懸念にこたえる内容じゃないじゃん。
そりゃ議題に上がるのは当たり前でしょうよ。現状XUL使ったAdd-onが多いなんてわかってんだから。
実際どうするのかってとこまで話が進めば別だけど。
Re:Firefox というブランド名だけ残したいということ？ (スコア:1)
そもそも「現在は議論の初期の段階」っていう前置きをしての話なのに、いったい何を期待してるの？
Re: (スコア:0)
期待なんかしてないよ。
当然クリアされる懸念だとでも思ってんの？
要出典 (スコア:0)
> XUL/XBLはマルチプラットフォームに対応するライブラリで、ユーザーインターフェイスの構築や各種ネットワーク通信などの機能を備えている[要出典]。
Re: (スコア:0)
XMLは所詮はテキストなんだから、マルチプラットフォームはウソじゃない。となれば、「ネットワーク通信」くらいしか引っ掛かるところはないな。
https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul [mozilla.org]