最初のβ版が登場してからまだほとんど日の経っていないGoogle Chromeだが、確実にそのシェアを延ばしている。この傾向が続けば、2008年9月にはWebブラウザシェア第4位を占めるのは間違いないだろう。どのタイミングでSafariと同じシェアに到達するかが最初の注目ポイントといえそうだ。

ユーザにとってはこうした有益なアプリケーション候補が増えることは好ましいことだが、Webデベロッパにとっては頭の痛い問題だ。ただでさえクロスブラウザ実装が面倒だというのに、今度はこれにGoogle Chromeも加わることになる。Webデベロッパ、特にJavaScriptプログラマが気になるのはGoogle Chromeのその魅力的な機能よりも、既存のWebブラウザと比較してどの程度違いを持っているのかということだろう。

この点に関してMozilla Foundation, JavaScript Evangelist, John Resig氏がJavaScript in Chromeにおいて調査結果を報告しているのでチェックしておきたい。結論を先にまとめると、現状でいくつかのバグと未サポート機能があるものの、将来のリリースで改善されると報告されておりGoogle Chrome特有の問題に頭を悩ませることはないだろう、ということだ。

もっとも顕著な問題は、基本型を含むプロパティをfor inループ構文でアクセスした場合に、その出現順序がソースコードの記述通りにはならない点にある。ECMA-262の規定に従えばこれは誤った動作ではないものの、ほかのWebブラウザがすべてソースコードの記述順序をそのまま保持することから、Google Chromeのこの動作には問題がある。開発チームはこの動作をすでにバグとして認識しており、将来のバージョンで修正するとしている。

テキストノードに<や>を含めた場合に<や>にシリアライズされないという問題もあるが、ベースとなるWebKitではすでに修正されたバグであるためGoogle Chromeでも将来のバージョンで修正されるとみられる。またGearsを同梱するためHTML5互換のクライアントサイドストレージAPIがサポートされていない点に関しても、将来のバージョンで対応するとのことだ。

さらに興味深いポイントとして、タイマー性能を改善し将来的には遅延が発生しないようにしたいと開発者が意見をあげているところに注目したい。JavaScriptはシングルスレッドで動作するため、さまざまな処理がタイマーで非同期的に処理を実行している。このため必然的にタイマーは保証されない動作になり、最大でも10ミリ秒から15ミリ秒の精度しか保証されない。Google Chromeではタイマー処理を改善し、より性能のいいタイマーを提供したいとしている。

Safariで採用されているWebKitはタイマーに関しては優れた性能を提供していることがJohn Resig氏の指摘で明らかになっており、今後Google Chrome開発の成果がWebKitにバックポートされた場合、Safariのタイマー性能も向上する可能性がある。現在のところGoogle Chromeの動作はWebKit/Safari 3.1とそれほどかけ離れておらず、Webアプリケーション開発で特別対応を迫られるブラウザというわけではなさそうだ。むしろ将来のバージョンでは、JavaScriptアプリケーションを実行するための魅力的なプラットフォームになる可能性が強い。