最近prototype.jsではSelectorとDOMがよく動きます。 仕事でも使っているし、重要な部分なのでここのところウォッチしています。

最近、実は書こうと思ってたElement.extendの問題が解決されました。 問題：Incredible memory leak in IE

これは見る人が見ればパッと見で「これはヤバいんじゃね？」と思ったんじゃないでしょうか。 わからなかった人は上記のURLにも載っている http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ietechcol/dnwebgen/ie_leak_patterns.asp を見ておくと今後悩むことが減るかもしれません。

リンク先をみたらなにが問題かわかるのであえては書きません。

もう一個、興味深いのはElement.extend cripples $() performanceでの議論です。 前に書いた記事と似た主張や議論がなされています。うちの会社にも英語苦手な人がいるので簡単に要旨を。

• Element.extendはパフォーマンスに問題がある。前のままにしてほしい。
• http://dev.rubyonrails.org/changeset/4094でだいぶマシになっているよ？ 解説：以前はそれぞれのElementについてElement.Methodsのメソッドにelementをbindしてコピーしていた。       つまりElementの数に比例してメモリを使用する。しかし4094でキャッシュを導入したので一定数のメソッドしか生成しない。
• とりあえずElement.extendのパフォーマンスをあげることにフォーカスしよう。
• Element.extend = Prototype.Kってかけばとりあえず大丈夫じゃね？
• でもscriptaculousが完全にextendされてる前提でコードかいてるから動かなくなるじゃん。       解説：scriptaculousは3月28日にprototype.js 1.5_pre1をバンドルしてバージョン1.6をリリースした。       このバージョンではelement.setStyle({top: ''})とかelement.show();みたいにガンガンElement.extendを活用している。
• まぁとりあえずElement.extendが必要ないときはPrototype.Kにしとけばいい。
• FirefoxやSafariは高速化できる（前のエントリーとほぼ同じ）。しかしprototype.jsに組み込むとscriptaculousのElement.Methods拡張が反映されない。

というわけでElement.extendはこれでちょっと落ち着いた感じ。個人的にはElement.extend無効化して使っていきたいなーって思ってたりしてたんですけどscriptaculousがやっぱりガンガン使ってきたので、まぁ様子見てみます。