拡張機能jsm化について

dynamis (でゅなみす/レッサーパンダ) @dynamitter

汎用的な js code module ってあまり公開されてないのかなぁ。まとめようと思ってもそもそも Mozilla 謹製以外は殆ど検索しても出てこない。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

@dynamitter http://www.cozmixng.org/repos/piro/fx3-compatibility-lib/trunk/ ここにちょこっとありますお

dynamis (でゅなみす/レッサーパンダ) @dynamitter

いつも頼りの Piro たん！っと最初に見てみてたんですが、jsm 形式のものは http://bit.ly/aBEL4F くらいしか見つからなかったのですが、どうなんでしょう？

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

http://www.cozmixng.org/repos/piro/fx3-compatibility-lib/trunk/prefs.js とかはEXPORTED_SYMBOLSを頭に書き足してツリー型タブ等でjs code moduleとして使ってる

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

JavaScriptコードモジュールが「えぇぇぇー」って感じなのは、複数のアドオンで同じライブラリを使っててもそれぞれのアドオンで別々に同じファイルを持ってなきゃいけないっていう点だ。だからあまり好きじゃない。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

なので http://www.cozmixng.org/repos/piro/fx3-compatibility-lib/trunk/animationManager.js なんかはなるべく1つのインスタンスを同じライブラリを使う全アドオンで共用するように設計してる

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

リビジョンが違っても大丈夫なように、API的には後方互換を保つようにするという自分ルールも決めてる。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

@piro_or うん。そこは激しく同意します。アドオン間で js code module を共有するための code module を書きたくなってきている今日この頃です。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

@dynamitter という感じでどちらかというと自分は1つのwindowの中に読み込ませるのが好き派なので特には書いてないですけど、 http://bit.ly/d2vldz という風にすればJS Code Moduleとして使えるはずです。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

あとtimer.jsmはJSDeferredをJS Code Moduleとして使うために作った物なので、ということはこれを使えばJSDeferredみたいなライブラリをそのままJS Code Moduleにできるという！

dynamis (でゅなみす/レッサーパンダ) @dynamitter

@piro_or 一方で、いちおうグローバル変数が切り離されてることや、性能上一度しか読み込まれないというのはやはり最終的に有意なんじゃないかと思うので、js module 推進派な今日この頃になってます。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

jstimer.jsmだた

dynamis (でゅなみす/レッサーパンダ) @dynamitter

@piro_or おおぉぉぉ。そのまますぐに Code Module にできる (browser.xul 側の window などのオブジェクトや XMLHTTPequest のようなクラスに依存しない) 独立性高くなってるのねー。すばらしいー。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

@dynamitter jQueryのJS Code Module化で使ってたテクニックをそれ単体でモジュール化したらいいんじゃないでしょうか。jstimer.jsmみたいに「既存ライブラリを最小限の変更でそのまま使うためのライブラリ」は、あるとできる事が一気に広がる気がします。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

@dynamitter そういえばwith(window)と書くよりはひょっとしたら(function() { ... }).call(window) の方がいいのかもという気がしました。「withは遅い」と以前@amachangさんがおっしゃってたので。

Piro🎉"ｼｽ管系女子"ｼﾘｰｽﾞ累計5万部突破!!🎉 @piro_or

でもあれはwith(node.style){...}をvar style = node.style;みたいに一旦キャッシュする形に書き換えるという話とセットだったような気もする。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

@piro_or えぇ、何かもうちょっと試行錯誤してみてそれなりに使えそうになったらまた適当に公開していろんなライブラリを XUL から使ってみる実験とかしてみたいと思ってます。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

なんか、Jetpack の既存 WebDeveloper が参入しやすい流れとか、高速化のベストプラクティスとか、うまく KB 化、定型化することでこれまでどおりの拡張機能開発もまた再活性化できないかなぁと思ってて...

dynamis (でゅなみす/レッサーパンダ) @dynamitter

@piro_or with はスコープチェインを追加するから多少は遅くなるのは当然なんですが、周りの速度評価とかはまだ全然行ってません。取りあえずまだ、動く、いろんなアドオンと試して互換性問題を起こさないというのを検証してる段階なので。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

一段落したら最新の JIT エンジンの元でも気にするほどの速度差が生じるのかとか、他に方法はないのかとかそういったところも検証したいとは思っていますが、取りあえず先延ばししまくりモードなのでだれか変わりにお願いモードです。(^^;

dynamis (でゅなみす/レッサーパンダ) @dynamitter

with 遅いというのはサイ本にかかれていることで非常に有名だけど、そんなの過去のエンジンの話だという噂もあれば、やっぱ比較すればそれなりに気になる重さだよとか、原理的にはどうせローカル変数にキャッシュすれば問題ないのではと思ったり、イマイチ判断しかねてます。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

速度比較も殆どはループ内部で殆ど何もしてないようなもので、実際の中身のあるループで比較するなら実用レベルでの影響がホントに生じるのかピントこない。JIT されてもなお影響あるのかとかという疑問もあるし(例えば関数インライン化の高速化は JIT により無意味になってるとか)。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

@piro_or ちなみに、Piro 先生、hiddenWindow にオブジェクト入れちゃうのって拡張機能的にはアリなんでしょうかね(互換性問題起きる可能性ある)？ と、誰にも分からないことを効いてみる。

dynamis (でゅなみす/レッサーパンダ) @dynamitter

hiddenWidnow 上にモジュール管理オブジェクト読み込んでそこに欲しいモジュールが登録済みか問い合わせ、あれば再利用、なければ import とかいうにすると拡張機能間で同じモジュール使っても共有できるんじゃないかなとか漠然と思ってるところ...

dynamis (でゅなみす/レッサーパンダ) @dynamitter

拡張機能のための JS コードモジュールのまとめページ (の元) を独断と偏見で書き始めてみた。 http://bit.ly/9uioYJ オススメライブラリがあったら追記してね！