セレクタ検索を独自に実装されている方は多いと思いますが、どうにもIE（特にIE6、7）が遅いと感じることはありませんか？
もちろん、JScriptのエンジン自体が遅いからなのですが、それ以外にもちょっとしたことで速度が改善したりします。
特に私が感じたのは、「NodeList」のループの部分です。
var list = document.getElementsByTagName(‘p’);
for (var i = 0; i < list.length; i++) {
// do something
};
と書くことが多いかと思います。しかし、これは遅いです。
var list = document.getElementsByTagName(‘p’), len = list.length;
for (var i = 0; i < len; i++) {
// do something
};
これだと数倍早く動きます。600回くらいのループで検証しました（内部処理は++countくらいで）が、
前者はIE6で約500ms、後者だと20数msでループが完了しました。
NodeListはSnapShotではなくLiveなものだから、ループの際に逐一「.length」の変化を見てるのかな？
もしくはNodeList.lengthのアクセス自体が遅いのか。
どちらかはわかりませんが、とにかくループ前にNodeListの長さを変数に格納してループすると
早くなるようです。
「数msくらい気にしない」、もしくは「IEはこんなもん」と思うのならさほど気にしなくてもよさそうですが、検索が遅いとその後の処理も遅くなってしまいますよね。
※どうもセレクタ検索を書くと速度のチューニングにハマって仕事にならないですね。
とりあえずトータルではjQueryより早ければいいかな。

IE8が出てしばらく経ちますが、やはりIEの独自仕様に悩まされることは多々ありますよね。
addEventListenerがattachEventだったりgetAttribute(‘className’)だったりnew ActiveXObjectだったりで・・・。
「Firefoxだけで動けばいい」という開発だったら工数は3分の1になりそうな感じです（ライブラリ未使用で）。
とはいえ、最近はIEの挙動不審が可愛く思えてきました。
「手間のかかる子ほど可愛い」とはよく言ったものですが、
ここまで手間がかかると逆に面白いくらいです。
もしもこの世界にIEしかなかったとしたら、それはそれで面白いことになりそうな気がしますね。
JavaScriptの至上命題は「クロスブラウザ」、これに尽きます。
いろいろと動くアプリケーションは簡単に設計できますが、「どのブラウザでも動く」アプリケーションは難しい。
本当に難しい。canvasなんて使った日にはもうお手上げでしょうか。
「IEの実装差分をどれだけ吸収できるか」が良いJavaScripterなのかもしれません。
・・・さすがにIE5とかは手がつけられませんが（笑）

自分のフレームワークを使っていて、どうにもGoogleChromeだけが動かない事態が発生しました。
IEだけ動かない、というケースには慣れっこですが（笑）、Chromeだけ動かないのは少し驚きました。
var e = hogehogeGetElement();
var native = e.hugahuga();
みたいなコードが動かなくて困りました。他のブラウザでは全部動いているのに・・・。
何がダメなんだろう、と試行錯誤の末、変数名を変えたら動いた。
var n = e.hugahuga();
「native」ってChromeでは予約語なのかな？この変数を定義すると動かないんですよね。
ちょっと稀な経験をしてしまいました。

最近はそれほどでもないですが、IE6などでは「後方互換モード」になるケースが多々あります。
DOCTYPEスイッチだとか、いろいろな要因で後方互換モードになってしまうのですが、ここいらで簡単にチェックできる方法があるのでご紹介したいと思います。
javascript:alert(document.compatMode);
こんなJavaScriptをロケーションバーに打ち込んでみてください。ダイアログが出てきます。
CSS1Compat
もしくは、
backCompat
なんてアラーとが出ますね。「CSS1Compat」なら標準モード、「backCompat」なら後方互換モードでレンダリングされている、という感じです。
最近のモダンブラウザなら大概はCSS1Compatでしょうが、IE6等でレイアウトが決まらないときにはチェックしてみるのもいいかも知れませんね。
・・・知ったからどうなの？というのは別問題ですが＞＜参考までに。

最近新しく発刊された某書籍でJavaScriptで要素のCSSの値を数値で取得するところが気になった。
みなさんは普段どうやられているのかわかりませんが、要素elmを取ったとして、widthの値を数値で取る時、
var width = parseInt(elm.style.width)
と私はやります。書籍では、
var width = eval(elm.style.width.replace(‘px’, ”))
ってやってた。う～ん、まぁこの方法もアリだとは思うんですけど。
前者だとisNaNのチェックが必要になる分手間かな、とも思ったのですが、後者は結局undefinedのチェックをしないといけないわけで。どっちも一緒かもしれないですね。
時間があったので1000回繰り返す速度計測してみた。どうでもいいだろうけど。
window.onload = function() {
var div = document.getElementById(‘test’), w, w2;
var st = (new Date()).getTime();
for (var i = 0; i < 1000; i++) {
w = parseInt(div.style.width);
w = (isNaN(w)) ? div.style.width : w;
}
var ed = (new Date()).getTime();
var time = ed – st;
alert(‘result : ‘ + w + ‘ , type : [...]