Toshiro Shimura's List: New Internet Explorer

• .NET  Framework環境の利点の1つと言われているものに、サイドバイサイド技術というものがあった。これは、アプリケーションのランタイム環境や実行時に必要とするDLLを実行ファイル単位に用意することで、.NET  Framework 1.1の実行環境と.NET Framework  2.0の実行環境が同じマシンに同居でき、しかもお互いに干渉しないようにできるということだ。

   

  　それなら、.NET Framework  1.xアプリケーションをわざわざマイグレーションしなくても済みそうなところだ。そのままサイドバイサイドで実行させ続ければよいからだ。

   

  　ここで問題となるのが、マイクロソフト製品のサポートライフサイクルだ。

• 2002年4月にVisual Studio .NET 2002と.NET Framework 1.0が登場してからすでに6年以上が経過した。今や.NET  FrameworkはWindowsプラットフォームだけでなく、Silverlight 2によってそのほかのプラットフォーム進出までも果たしている。

   

  　Windowsプラットフォームでの開発にはもはや欠くことのできない.NET Framework。だが、1.0の登場当時、特にVisual  Basicを開発言語に用いている技術者にとっては、完全なオブジェクト指向へのパラダイムシフトを必要としたせいか、移行にはそれなりの時間がかかったように記憶している。そのためか、.NET  Frameworkが本格的に普及したのは、マイナーバージョンアップとなった.NET Framework 1.1になってからだった。

• 1つの転換期となったのは、Visual Studioが2005へとバージョンアップし、同時に.NET  Frameworkも2.0に進化したときである。Visual Studio 2005に搭載されたアップグレードウィザードが、Visual Basic  6.0のプロジェクトの変換を効率的に行えるようになっていたため、Visual Basic 6.0からの移行は、.NET Framework  1.xを通さず、直接2.0へと行われたものも少なくない。

   

  　2007年11月にはVisualStudio 2008が登場し、.NET  Frameworkのバージョンは3.5となった。2008年8月にはVisualStudio 2008および.NET Framework 3.5  サービスパック（SP）1が登場し、現時点での標準的な開発環境はWindows Server 2008＋SQL Server 2008＋.NET  Framework 3.5SP1＋Visual Studio 2008SP1となった。

• ここで注目したいのが、.NET Framework  2.0から3.5の間は、ランタイム環境であるCLRのバージョンが変わっていないということだ。開発環境とクラスライブラリが異なるだけで、.NET  Framework 2.0アプリケーションと.NET Framework 3.5アプリケーションでは実行環境に違いがないことになる。

   

  　つまり現在では、レガシーに分類されてしまうであろうVisual Basic 6.0以前のアプリケーションと、.NET Framework  1.xベースのアプリケーション、そして.NET Framework 2.0ベースのアプリケーションが存在することになる。

   

  　今、アプリケーション移行（マイグレーション）を考えた場合、必然的に.NET Framework  1.xベースのアプリケーションに注目することになる。なぜなら.NET Framework  2.0ベースのアプリケーションは実質的に最新のアプリケーションと言ってもよいため移行対象にはならないし、Visual Basic  6.0以前のアプリケーションについては移行するしないで悩むレベルでなく、捨てるか、移行するか、新規開発かを「選択しなければならない」時期は過ぎて、すでに判断されているはずだからだ。

   

  　.NET Framework  1.xベースのアプリケーションも今、捨てるか、移行するか、新規開発かの選択を迫られている。とはいえ、.NET以前からの移行に比べ、Visual Studio  2008への移行は楽なので、新規開発という選択肢を用意する必要はないかもしれない。実際は、移行するかしないかについて判断することになるだろう。

2 more annotations...

• IE 8 β2のあらゆる新機能の中で、わたしが恐らく最も多用したのは、ブラウザをIE  7のエンジンに切り替える互換モードだろう。アドレスバーの横に表示される壊れたファイルのアイコンのようなボタンをクリックすると、サイトが互換モードでリロードされる。わたしのテストでは、多くの人気サイトや一般的なサイト、WebメールやGoogleのアプリケーションサイトでさえも、このモードをかなり頻繁に使わなければならなかった。互換モードが必要なのは標準に完全準拠していない古いサイトのみだとMicrosoftは説明していたので、Web  Standards ProjectとAcid Web標準テストのサイトであるwebstandards.orgのサイトでも互換モードを使わなければならなかったことには少なからず驚いた。

• わたしのテストで本当に重宝したIE  8の機能は、クラッシュ対策とページ復旧の新機能だった。なぜなら先に触れた通り、β2はわたしのテストでは非常に不安定だったからだ。幸いなことに、新しい復旧機能は優れていた。1つのタブに表示しているWebサイトが問題を起こした場合、データはそのままでそのタブのみが更新され、ほかのタブには影響を与えない。ブラウザ全体がクラッシュした場合はタブがすべて自動的に復旧され、サイトのデータはそのままだった。

   

  　IE 8 β2の標準対応はIE 7に比べてかなり改善され、IE 8はWeb Standards  ProjectのAcid2テストにも合格している。しかし、β版では新しいAcid3テストの成績はかなり悪く、現行世代のほかの全ブラウザに比べて相当後れを取っている。

   

  　開発者の観点から見ると、IE 8  β2はこれまでのバージョンよりもかなり親しみやすそうだ。非常に優れた開発ツールがブラウザに統合され、Webサイトのコードのテストやデバッグが手軽にできる。また、新機能の多くは開発者にも利用できる。

• わたしの判決はこうだ。Chromeはスマートで革新的なブラウザであり、多くの一般的なケースでは、Webの利用はより速く、簡単になり、不満も少なくなる。だが最初のバージョン――まだβ版だ――は荒削りで、Googleが後で追加する予定の一般的なブラウザ機能が幾つか欠けている。ブックマーク管理、ブラウザから直接リンクやページを電子メールで送るためのコマンド、さらにはWebページのロードがどのくらい進んだかを示すプログレスバーもない。

   

• GoogleはChromeは高速だと主張しているが、わたしがテストしたところでは、Webページを開くという普通の作業で、FirefoxやSafariよりも目に見えて遅かった。だが、IEの最新版――こちらもβ版で、IE 8という――よりは速いことが判明した。

   

  　一方のMicrosoftも何もしていなかったわけではない。IE 8のβ2はここ数年で最高のIEのバージョンだ。新しい独自機能が詰まっており、中にはChromeに似た機能も、わたしから見ればChromeに勝る機能もある。

• 例えば、IE 8も関連するタブをグループ化するが、それぞれのタブグループに異なる色を割り当てており、クリック1回ですべてのタブを閉じることができる。独自の「スマートな」アドレスバーがあり、入力している途中で候補のドロップダウンリストが現れる。ただし検索ボックスは別になっている。

   

  　またIE 8にはChromeをしのぐ画期的なプライバシー機能があり、「アクセラレータ」という新機能もある。アクセラレータは、Webページ上で地名を選択して地図を表示するといったように、ページ上で選択した単語やフレーズに対して、新しいページに移動せずにすぐに何らかの操作ができるというもの。

   

• Googleはなぜ新たなブラウザ戦争を始めようとしているのだろうか。主な理由は2つあり、どちらもMicrosoftとの競争に関係している。1つは、Googleの検索エンジンや主要製品はブラウザに依存しているため、同社は、オンラインで競合するMicrosoftが、約75％のシェアを持つIEの設計を変えることで有利な立場に立てるかもしれないと懸念している。

   

  　2つ目の理由はもっと重要だ。現在アプリケーションはコンピュータOS、特にMicrosoftのWindowsから直接実行されているが、GoogleはWebをアプリケーションのプラットフォームとしてとらえている。同社は、今のブラウザには、JavaScriptを多用した将来の強力なWebアプリケーションを実行できる基盤設計がないと主張している。Chromeは、世界で最もJavaScript処理が高速なブラウザを目指して設計された。

   

  　これによりChromeはいつか、Windowsと張り合うオンラインOSのようなものになるかもしれない。「ChromeをシンプルなWebブラウザ以上のものとして考えてほしい」とGoogleは宣言している。「これはWebアプリケーションを実行するためのプラットフォームだ」

• Chromeと一般的なWebサイトとの互換性についてもテストしてみた。結果はおおむね良好で、サイトは正しくレンダリングされた。だがビデオでは問題が起きた。一部のビデオサイトではChromeが認識されなかった。Chromeの開発が秘密にされていたためだ。メジャーリーグのサイトなどほかのサイトでは、ほとんどのビデオが再生できたが、うまくいかないときもあった。

   

  　IE 8にも、いろいろな理由から多少の互換性問題がある。同ブラウザは、Web標準に厳密に準拠する初めてのIEのバージョンだ。これまでのバージョンは、Webサイトのレンダリングを標準的でない方法で実行していたため、一部のWebサイトデザイナーはIEではページを正しく表示できるが、FirefoxやSafariでは表示が崩れるような手法を採用していた。皮肉なことに、今はそうしたページがIE 8で正しく表示されなくなっている。そこでMicrosoftは、サイトを正しく表示させる「Compatibility View」ボタンを組み込まなければならなかった。

3 more annotations...

• Google Chromeの開発で最重要視したのが使いやすさとパフォーマンスであり、Googleが開発を進めてきたJavaScriptエンジン「V8」とAppleが無償公開するレンダリングエンジンの「WebKit」の組み合わせがその原動力になるという。V8という名称はV型8気筒エンジンに由来する。米国製自動車ではV8エンジンが高性能を表現するステータスシンボルであり、Google ChromeのV8はそのシンボルにあやかって命名されたものであるという。

   

  　V8はデンマークを拠点に活動しているJava VM開発のエキスパート、ラーズ・パーク氏のチームが20年近く蓄積したノウハウを反映させて実現したものだと、アプソン氏は説明。「既存の処理性能を何倍にも高速化することに注力し、今後のWeb世界での標準になることを目指したものだ」（同氏）

   

  　WebKitの採用理由について、同氏は「Safariでの採用実績に加え、描画処理性能の素晴らしさをわれわれも重視した。WebKitプロジェクトには、特に“セーフティブラウジング”（クラッシュなどの影響を最小限に抑えるなど）の部分で積極的にかかわってきた経緯もあり、Google ChromeではWebKitの成果を活用した」と話した。WebKitを採用することで、Web開発者がGoogle Chrome用に新たな開発を行わずに済むよう配慮したとも、同氏は説明した。

   <!--CAP--> 

   アドレスバーと検索窓を兼ね備えた「多機能ボックス」や各タブが独立して実行する仕組みはシンプルさと使い勝手を追求した結果であるという

   <!--CAPEND--> 

  　グーグルが独自に実施したレンダリングパフォーマンスの比較では、ローカル上に保存した複数サイトのWebページを連続表示させた場合、Internet Explorer 7では約257ミリ秒、Firefox 3では158ミリ秒、Google Chromeでは68ミリ秒という結果になった。

• Google Chromeの開発で最重要視したのが使いやすさとパフォーマンスであり、Googleが開発を進めてきたJavaScriptエンジン「V8」とAppleが無償公開するレンダリングエンジンの「WebKit」の組み合わせがその原動力になるという。V8という名称はV型8気筒エンジンに由来する。米国製自動車ではV8エンジンが高性能を表現するステータスシンボルであり、Google ChromeのV8はそのシンボルにあやかって命名されたものであるという。
  
  　V8はデンマークを拠点に活動しているJava VM開発のエキスパート、ラーズ・パーク氏のチームが20年近く蓄積したノウハウを反映させて実現したものだと、アプソン氏は説明。「既存の処理性能を何倍にも高速化することに注力し、今後のWeb世界での標準になることを目指したものだ」（同氏）
  
  　WebKitの採用理由について、同氏は「Safariでの採用実績に加え、描画処理性能の素晴らしさをわれわれも重視した。WebKitプロジェクトには、特に“セーフティブラウジング”（クラッシュなどの影響を最小限に抑えるなど）の部分で積極的にかかわってきた経緯もあり、Google ChromeではWebKitの成果を活用した」と話した。WebKitを採用することで、Web開発者がGoogle Chrome用に新たな開発を行わずに済むよう配慮したとも、同氏は説明した。
  
  
  アドレスバーと検索窓を兼ね備えた「多機能ボックス」や各タブが独立して実行する仕組みはシンプルさと使い勝手を追求した結果であるという
  　グーグルが独自に実施したレンダリングパフォーマンスの比較では、ローカル上に保存した複数サイトのWebページを連続表示させた場合、Internet Explorer 7では約257ミリ秒、Firefox 3では158ミリ秒、Google Chromeでは68ミリ秒という結果になった。 - Toshiro Shimura on 2008-10-04