アカウント名:
パスワード:
APIが揃うのは良いが、開発者やユーザーへの訴求、取り込み方法はどうするんだろう。Chrome拡張機能のアーカイブであるcrxファイルをそのままインストールできるぐらいにしないと、わざわざChromeからFirefoxへの移植版なんて作ってもらえないと思う。
未だにFirefoxってMSIファイルもないし、本体にグループポリシー設定機能もないし、本気でシェアを分捕るつもりあるんだろうか。確かな野党とかに近い考えだったりして。
その割には拡張機能をWebExtensionsに一本化なんて話もありますよね。自ら多様性を捨ててChromeと同質化していくFirefoxに存在する意味があるのかどうか。リソースがなくてOperaみたいにギブアップするなら分かるんですが、エンジン開発を続けながら偽Chromeを作る意味はなんなんだろう。少なくともユーザーには何もメリットは無いですよね。
Chromeとよく似たUIで乗り換えが簡単です。←分かるもちろんChromeに無い機能はありません。←乗り換える意味は?
> その割には拡張機能をWebExtensionsに一本化なんて話もありますよね。
標準化のために作られたAPIに対応する行為自体は問題ないだろう。問題のあるのは、標準化されることのない独善的な仕様に依存することだろう。独善的な仕様に依存して、さらに実装の多様性も失われたら、あとは実装者の思うままになる。
標準APIに対応することで、APIの使い方等のドキュメントやサポートのコストが減らせる。開発のリソースを節約するとか、もっと別のところに集中できるかもしれない。
> 少なくともユーザーには何もメリットは無いですよね。
オープンの精神というか、そういうのじゃないから。
> 問題のあるのは、標準化されることのない独善的な仕様に依存することだろう。> 独善的な仕様に依存して、さらに実装の多様性も失われたら、あとは実装者の思うままになる。
それ自体は激しく同意。実際かつての IE において証明されている。
だが、昨今の Firefox(と云うより Mozilla)において問題なのは、多様性を持たせようとはしていない事。WebExtensions を導入し、Chrome 互換の拡張と旧来の実装の拡張が併存するなら、別に反対する開発者も居ないと思われるが、Mozilla は実績ある実装やスタイルを切り捨て、新しいスタイル(と云っても大半が
Firefox も、旧 Mozilla ブラウザ (SeaMonkey) を下克上して、Mozilla のメインプロジェクトになったわけだし、破壊的イノベーションを全部否定するわけじゃないけど、古いものの廃止は新しいものが取って代わるに十分であることが示されてからにして欲しいね。
# ま、今の拡張機能のメイン要素の XUL, XPCOM, RDF といったところを、新規のひとに今から学ぶことをオススメ出来るかといえば…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
部分的じゃなくて完全互換にしろよ (スコア:0)
APIが揃うのは良いが、開発者やユーザーへの訴求、取り込み方法はどうするんだろう。
Chrome拡張機能のアーカイブであるcrxファイルをそのままインストールできるぐらいにしないと、わざわざChromeからFirefoxへの移植版なんて作ってもらえないと思う。
未だにFirefoxってMSIファイルもないし、本体にグループポリシー設定機能もないし、本気でシェアを分捕るつもりあるんだろうか。
確かな野党とかに近い考えだったりして。
Re: (スコア:0)
MozillaがWebKitを使わず独自エンジンを開発するのは、まさにそういう理由だよ。
Webの多様性云々
Re: (スコア:0)
その割には拡張機能をWebExtensionsに一本化なんて話もありますよね。
自ら多様性を捨ててChromeと同質化していくFirefoxに存在する意味があるのかどうか。
リソースがなくてOperaみたいにギブアップするなら分かるんですが、エンジン開発を続けながら偽Chromeを作る意味はなんなんだろう。
少なくともユーザーには何もメリットは無いですよね。
Chromeとよく似たUIで乗り換えが簡単です。←分かる
もちろんChromeに無い機能はありません。←乗り換える意味は?
Re: (スコア:0)
> その割には拡張機能をWebExtensionsに一本化なんて話もありますよね。
標準化のために作られたAPIに対応する行為自体は問題ないだろう。
問題のあるのは、標準化されることのない独善的な仕様に依存することだろう。
独善的な仕様に依存して、さらに実装の多様性も失われたら、あとは実装者の思うままになる。
標準APIに対応することで、APIの使い方等のドキュメントやサポートのコストが減らせる。
開発のリソースを節約するとか、もっと別のところに集中できるかもしれない。
> 少なくともユーザーには何もメリットは無いですよね。
オープンの精神というか、そういうのじゃないから。
Re: (スコア:0)
> 問題のあるのは、標準化されることのない独善的な仕様に依存することだろう。
> 独善的な仕様に依存して、さらに実装の多様性も失われたら、あとは実装者の思うままになる。
それ自体は激しく同意。実際かつての IE において証明されている。
だが、昨今の Firefox(と云うより Mozilla)において問題なのは、多様性を持たせようとはしていない事。
WebExtensions を導入し、Chrome 互換の拡張と旧来の実装の拡張が併存するなら、別に反対する開発者も居ないと思われるが、Mozilla は実績ある実装やスタイルを切り捨て、新しいスタイル(と云っても大半が
Re:部分的じゃなくて完全互換にしろよ (スコア:0)
Firefox も、旧 Mozilla ブラウザ (SeaMonkey) を下克上して、Mozilla のメインプロジェクトになったわけだし、
破壊的イノベーションを全部否定するわけじゃないけど、古いものの廃止は新しいものが取って代わるに十分であることが示されてからにして欲しいね。
# ま、今の拡張機能のメイン要素の XUL, XPCOM, RDF といったところを、新規のひとに今から学ぶことをオススメ出来るかといえば…