Google Chrome曰く「Webブラウザは主役じゃない」（3/4） ─ ＠IT

● ChromeをWebアプリ実行の“プラットフォーム”として考えると……

　しかし、Chromeを「Webアプリケーションの実行プラットフォーム」として考えれば、何の不思議もありません。

　例えば、Windowsアプリケーションを使い、ワープロと表計算とメーラとスケジュール管理を開いて仕事をしているとします。この場合、これらのアプリケーションソフトは別々のプロセスを持っています。だから、例えばワープロがクラッシュしても、メーラが落ちることはなく、書きかけのメールが消えてなくなることもありません。

　ところが、従来のWebブラウザ上から使うAjaxアプリケーションの世界では話が変わります。Ajaxアプリケーションのワープロと表計算とメーラとスケジュール管理を開いて仕事をしているとき、ワープロがクラッシュするとすべて道連れです。クラッシュリカバリ機能が救えるデータを救ってくれることはありますが、すべてを確実に救えるわけではありません。

　ですが、Chromeのアーキテクチャであれば、この問題が解消されます。タブごとに異なるプロセスで実行されるため、ワープロがクラッシュしてもメーラに影響は及びません。これは、「Webアプリケーションのプラットフォーム」として考えれば、長所です。

　Chromeを「Webアプリケーションの実行プラットフォーム」として考えると、「アプリケーション ショートカット」機能を含め、Webブラウザの機能を拡張することを目的として開発されていたGearsは、実はChromeのための布石だったのかもしれないという考えに至ります。

Highlighted by toshiro

● 使い比べた結果は……

　実際に、IE 7.0、Firefox 3.01と使い比べてみました。なんと過酷にも「Tokyo Subway Map（KML）」と「世田谷古道地図」の両方を同時にオンにしてみます。

図13　Chromeによる表示結果

図14　Firefox 3.01による表示結果

図15　IE 7.0による表示結果

　さて、結果が表示されるまでの待ち時間、ドラッグによってスクロールさせた場合のスムーズさなど、いずれの点でも以下の順番で優れた結果となりました。

Google Chrome 0.2 ＞ Mozilla Firefox 3.01 ＞ Internet Explorer 7.0

● 重いAjax／JavaScriptアプリの専用ブラウザとして使う？

　この結果を見たとき、思ったことは以下の3点です。

• 一般論としてChromeをメインのWebブラウザにするのは時期尚早だろうが、Googleマップ専用ブラウザとして導入するのはありかもしれない
• その場合、地図が見える面積が広いのは長所
• Chromeによる閲覧を前提とするなら、もっと重いマイマップを作成してもいい

　筆者個人の感想はGoogleマップ限定ですが、おそらくほかのAjaxアプリであっても同じような感想があり得ると思います。しかし、話はまだ続きます。

GearsはChromeのための布石だったのか？

　Googleマップ専用ブラウザとしてChromeを導入するとすれば、アプリケーション化は非常に便利な機能です。なぜかといえば、専用に使うということは、「Webブラウザを開く→Googleマップを開く」という2手順を費やす意味がないことを示すからです。アイコンから直接開いてくれればいうことはありません（もちろん、従来のWebブラウザでもお気に入りのショートカットをデスクトップに置くなどの対処はあり得る）。

　さらにいえば、この場合はアドレス入力ボックスが存在することに意味はありません。別のサイトを閲覧するためには使わないからです。むしろ、その分の面積にも地図を表示してくれた方がありがたいわけです。とすれば、Chromeのアプリケーション化という機能はジャストミートします。

Highlighted by toshiro

私はFirefox登場時に割と好意的な第1印象を感じました。事実か否かは分かりませんが、本当のプロが作っている手堅さを感じ取り、安心感があると思いました。しかし、その後Firefoxはバージョンアップごとに手堅さが低下し、不安感が膨らんできた感じを受けます。

　そして、Chromeを見て感じたのは、Firefoxを最初に見たときと同じような手堅さ、安心感です。まだベータ版なので、今後どうなるかは分かりませんが、少なくともその点で好感を感じました。

　さて、最後に2つの話題に触れてこの話を終わりたいと思います。

● Androidのようなモバイルデバイスの展開と連動する可能性

　手堅く軽いChromeは、当然PC以外のプラットフォームへの展開もあり得るでしょう。例えば、WebKitを用いていることからも容易に予測できますが、Google Androidのようなモバイルデバイスの展開と連動する可能性も十分にあり得ると思います。

　モバイルやローカル実行という技術を含めてWebアプリケーションとChromeという組み合わせを考えれば、Webの秩序を変えてしまうような何か大きな“出来事”もあり得るかもしれません。

Highlighted by toshiro

● Chromeの未来は一般開発者が決めるかのもしれない

　そして、それを引き起こすのはグーグルだけではなく、Chromeのパワーを活用していままでにないWeb（Ajax／JavaScript）アプリケーションを開発していく一般開発者もやはり“出来事”を起こす原動力となるのではないでしょうか。

　一般開発者が主役という点で考えると、Chromeの出現はGoogleマップによる「Ajax革命」時の衝撃と似たようなものがあります。Googleマップの出現によって、Ajaxアプリケーションを作る一般開発者が爆発的に増えたことは記憶に新しいと思います。

　その証拠にグーグルは、Chromeに前述のようなWeb開発者向け機能を標準で備えさせていたり、Web開発者向けに「ウェブ開発者向けのよくある質問」ページや「ヘルプセンター」も公開しているなど、一般開発者へのケアも怠っていないようです。

　いずれにせよ、未来は不確定であり、Chromeが未来を可能性に満ちた流動する世界に塗り替えたのは事実でしょう。

Highlighted by toshiro

このように考えると、実はChromeの真の存在意義とは、従来のWebブラウザと同じではないのかもしれない、と思えてきます。従来のWebブラウザは、主にページを閲覧するものであり、ページからページに渡り歩きます。そのため、ページを移動して個々のページをよりよく扱うための支援機能にあふれています。

● 普通のWebブラウザとはWebに対するアプローチが違う

　一方で、Chromeはそのような支援機能でウィンドウを飾ることは行っていません。その代わり、途轍（とてつ）もなく速いプログラムの実行速度と、広く見やすいウィンドウを提供しています。つまり、Chromeはページを渡り歩くことよりも、Webベースで提供される各種Ajax／JavaScriptサービスをよりよく使うための“プログラム”なのかもしれません。

　とすれば、「Chrome最大のなぞ」ともいえる、タブごとにプロセスを生成するという不思議な仕様が必然であることが理解できます。確かにプロセスを分ければ、1つのタブがクラッシュしてもほかに波及しないという効能はありますが、プロセスとはシステムから見れば重い資源です。

　例えば、タブを数十、数百と開けば、システム全体のパフォーマンスへの影響が懸念されます（実際、100を超えるタブを開くユーザーは実在する）。であるから、ほかのWebブラウザでは1つのプロセス内で複数のタブを扱う構造になっているのです。だから、普通の意味でWebブラウザの仕様を考えるなら、タブごとにプロセスを生成するという仕様は手放しで褒められるものではないのです。

Highlighted by toshiro