国民宿舎はらぺこ 大浴場

• Ajax うきうき Watch 第14回　IE7とFirefox 2への利用者の大移動は起こるか？ (@IT)

IE7 と Firefox 2.0 のリリースに関して

はやく日本語版出してくれ～＞IE7

いうまでもなく、Ajaxとは古いありふれた技術によって成立した技術体系です（※1）。それがブームになるためには、Internet Explorer 6.0のライバルたちが、同程度の機能を提供する段階に進化するまで待たされたという側面があると思います。もちろん、ライバルたちはInternet Explorer 6.0よりもエレガントに、より優れた機能を提供しようとしていました。

しかし、Ajaxという文脈で見た場合、それらはあまり意味がないといえました。なぜなら、Internet Explorer 6.0をサポートしようとする限り、Internet Explorer 6.0にない機能を使うことに対しては抑制的にならざるを得なかったからです。それ故に、Firefoxの大流行という現象は、Firefoxの優秀さというよりも、Internet Explorer 6.0との驚くほど高い互換性に原因を求めてもいいのではないかと思います。つまり、多くの場合、最も多数の利用者が使うInternet Explorer 6.0がAjaxサービスの不動の基準として機能していたことになるわけです。

とりあえず、「Ajaxという文脈」というのがどういう視点のものなのかがよく分からないので何とも言えないのですが、少なくとも現時点で「ライバル」と言えそうな PC 向けブラウザ (Mozilla/Firefox、Opera、KHTML/safari) が辿っていたのはあくまで「Web の標準化という文脈」なのであり、その文脈から見る限り、「Internet Explorer 6.0よりもエレガントに、より優れた機能を提供しようとしていました」というのはあまりにも頓珍漢な解釈だし、「Firefoxの大流行という現象は、Firefoxの優秀さというよりも、Internet Explorer 6.0との驚くほど高い互換性に原因を求めてもいいのではないか」という観測も何だかずれてるなぁという印象です。

IE が市場を独占することになった要因は、紛れもなく、かつて市場を分かっていた片翼の NN4.x があまりにもダメな実装だった為に、CSS ベースの HTML4.0 へと移行してゆこうという Web 文化において、IE の方が NN よりも圧倒的に「マシな」表示を行ってくれるブラウザとなったことにあります。当時は Opera も safari も存在していなかった (Opera は存在はしていたかも。。。) 為、技術面においても事実上 IE しか選択肢がなかったわけです。

で、Web 標準化に関しては Microsoft も提案者の一人であった (少なくとも形式上は) ので、その標準化に則って実装されている Gecko (Mozilla/Firefox) が IE と互換性が高いのは当然です。むしろ、Mozilla の最大の目標は、当時の現状としてデファクトスタンダードとなりつつあった IE の表示機能 (非 UI 機能) を、アクセシビリティを考慮しつつ標準化へ押し上げ整理し、それを Windows に限らない多くのプラットフォームにおいて動作するものとして実現することにあったわけで、Ajax の流行は所詮、そうした標準化の地合が整ったことをきっかけとして Google が引き金を引いたことによって生まれた副産物に過ぎません。

Firefox が流行した要因の一つとして、IE との互換性が無いと言うつもりは無いのですが、それだったら Opera はもっと普及していてもいいものだろうと思うし、要因の一つといえるほどポジティブなものと言うよりは、むしろ最低要件とも言うべきネガティブな要素とみるべきだと思います。

このような理由から、利用者よりも自分の美学を優先させる潔さを持ったサムライたちを除けば、Ajax開発者はどうしてもInternet Explorer 6.0に注目し、それを基準として作業せざるを得なかったわけです。しかし、長い間メジャーバージョンアップしないInternet Explorer 6.0は、基準となるよりどころとしては使いやすかったといえます。長所も短所も変化せずにいつもそこにあったからです。

しかし、Internet Explorerがバージョンアップするということになれば、「変化しない基準」が、変化しないままではいられないことになります。そして、Internet Explorerの6.0と7.0のどちらにより注目し、どちらをより尊重するのかという問題が発生します。もちろん、現実的な対応としては、多くの利用者が双方を使って利用する以上、どちらも使えるようにせざるを得ません。つまり手間が増えます。

IE6 と IE7 の間に、どれほどの変化があるのでしょうか? おいらが知る限り、XMLHttpRequest メソッドが正式に追加されたことを始め、既に提唱されている標準に近づくための変更 (新規追加、およびバグ修正) だけであり、まったく新しい技術の追加や、Web 開発者が目玉を飛ばしてひっくり返りたくなるような変更は特になかったように思います。少なくとも、「標準化を意識」していた Web 開発者は、それほど困らないように思います。本当に「IE6 を意識」しかしてこなかった Web 開発者は、確かに困るでしょうが、これを機に標準化を意識するよう気持ちを入れ替えるべきなのであって、「IE6 でも IE7 でも動くように意識」するのは間違いであることに気づくべきです。

もちろん、Firefoxの動向も同じような問題を引き起こす可能性があります。最悪のシナリオは、Internet ExplorerとFirefoxが互いをライバル視し、相互に互換性のない機能強化競争に突入することでしょう。Ajaxは、非互換性や分かりにくさ、複雑さといった問題を内包する技術であり、変化の少ない枯れた技術を集めたからこそ成立したといえる部分があると思います。しかし、これらの問題を残したまま変化の激しい時代に突入するとすれば、Ajaxは1つの危機に直面する可能性もあり得ます。

確かに、過去のブラウザ戦争のトラウマを持つ旧い人間にとって、その懸念は拭い去れないものかもしれません。しかし、IE7 の開発を巡る Microsoft の動きを見る限り、おいらはあまりこういう心配はしていません。Microsoft は IE を、少なくとも描画部分において、提唱されている標準へ近づけようとしています。そうしなければこのブラウザは生き残れないし、極端な話 Windows 自体が生き残れません (少なくとも欧米ではそういう危機感が生まれつつあります。そして、Microsoft の市場のターゲットはエロゲー王国日本だけではありません)。現状では IE7 を以ってしても、Firefox 1.5 および 2.0 に対しては、標準化という側面において 5 歩も 6 歩も引けを取っています (CSS2.0、Math-ML、built-in SVG、Punicode、JavaScript 1.5/1.6/1.7、etc...)。

IE7 の最大の意義は、IE の開発が再開されたということ自体にあるのです (もちろんこの功績の最大の功労者は Firefox です)。これによって、標準化のブレを懸念するのは間違いです。むしろ、提唱される標準の「実用化」という名のボトムアップが着実に進んでゆくことになるのを喜ぶべきです。既に提唱され、Mozilla や他のブラウザなどで既に実装されていながら、IE との互換性故に広く実用化されていない技術はまだまだたくさんあるのですから。

「発言せざる読み手」について

マスコミが作った俗説が、あたかも事実であるかのように広まってしまい、おかしな状況を作り出すことは珍しくありません。例えば、「インターネットは誰でも対等に発言する場である」……、つまり誰もが発言者にならねばならない（なることができる）というのは、その種の俗説の1つです。しかし、本来「発言」に対して「読み手」がいるのが自然な流れです。「読み手」の多くは自ら発言をしない人たちです。そのような「発言しない読み手」は、インターネットを成立させるために必要とされる正当な利用者の一種です。

(中略)

しかし、この「JSON+COMETでリアルタイム・ページビュー・カウンター」「『足あとライブ！』」「『足あとライブ！』にペンギンアイコンがやってきた」はなかなか面白いと思いました。これはまさに「発言せざる読み手」が能動的にかかわるための仕掛けにほかなりません。リアルタイム・ページビュー・カウンターや「足あとライブ！」は、同じコンテンツをほかの誰かも見ていることを知ることができます。そして、「ペンギン」は割と面倒な「言葉を考える」という手順抜きで、気軽かつ匿名的に自分の存在感をその場に示すことができます。

もしかしたら、ブログやSNSの未来にあるコミュニケーションシステムとは、このような機能性を正しくリッチに取り込んだシステムになるのかもしれません。

Connective Chat みたいに動くチャットをサイト上に小窓で表示して、同じドメインのサイトにアクセスしてる人同士でチャットができたりしたら面白いなぁとか考えていたので、足あとライブやペンギンはちょっとした衝撃でした。「発言せざる読み手」という考え方は、おいらにとっても盲点になっていたかもしれません。研究する価値はあるかも。。。

技術系な話題

このAjaxianのベンチマークを見ると、Opera 9.01、 Mozilla Firefox 1.5、 IE 6.0 32bit/64bitのいずれもinnerHTMLが最も優秀なキングであることが分かります。

innerHTML の方が高速なのか。。。ぼえぼえ～も squash も書き換えてみるべかなぁ。。。

フレームワークの方は、Prototype.jsが最も多く（43％）、その後はScript.aculo.us（33％）、Dojo（19％）と続きます。ちょっと意外だったのはGoogleが熱心だという印象があったGWT（Google Web Toolkit）が3％とかなり低いことと、なぜかマイクロソフトのAtlasが、それを超える4％もの数字を示していることです。ちなみに、GWTもAtlasもまだ正式版ではありません。

フレームワーク使ったことねぇｗｗｗｗｗｗ　まぁ、そのうちな。。。(^_^;

サーバ側プラットフォームの方は、1位のPHP（50％）の存在感は圧倒的ともいえます。難しい理屈をいわない分だけ、PHPの単純さと分かりやすさは抜きんでており、急速に拡大したWebプログラマからの支持を集めることができたのでしょう。一方、2位のJava（37％）は、思ったよりも多いという印象を持ちました。Ajax関係で目に触れるキーワードとしてPHPと比較すると、数分の1の頻度でしか見ない……という印象だったので。3位の.NET（16％）は具体的にどの言語で書いているのか分からないので、何ともコメントできません。

それとは別に印象的なのは、PerlがPython（6％）にも負ける5％という数字になっていたことです。Webプログラミング　イコール　CGI　イコール　Perlという図式で語られた時代は完全に過去のものになったようです。取りあえず、何か大きな事件でも起きない限り、PHP最強という図式は当分続きそうな気がします。

糞ったれ PHP ユーザーどもメ。(とか言いながら Pukiwiki は愛用していたりする ^_^;;)

mod_perl 普及しないよなぁ。。。何でだろ? やっぱり Perl4 時代の過去の資産が必ずしも動くとは限らないってのがアカンのかなぁ。PHP にベンチマークで勝てないから? そんな記事が過去にどこかであった気はするが、決してそんなことは無いのよ。安全面だって汚染モード備えた Perl の方が PHP より上だし (確かにバグ混入率は Perl の方が上かもだけど)。

まぁ、フォーム UI ベースのちょっとしたプログラムを作りたいだけだったら、確かに HTML に埋め込むような形で作れる PHP の方が圧倒的に便利ではあるけどね。でも PHP で大掛かりなアプリを作りたいとはとても思えない。。。実際はフォーム UI ベースのプログラミングは Perl でもヒアドキュメントで十分可能だし。

オブジェクト指向? PHP5 ってもう普及フェーズに入ってたっけ? 参照って概念すら十分に普及できてない言語コミュニティーがオブジェクト指向を重視した結果、ブロックスコープにすら対応していない PHP 言語を選択したとは到底思えないんだけど。

結局は「Web 開発者」という括りにおけるコミュニティーの質の問題なのかなぁ。。。確かに Perl は決して簡単な言語ではないと思う。そして mod_perl をテストする環境を構築するのは (Windows しか使えない多くの素人にとって) 非常にハードルが高いことだと思う。

もっとも、Python よりも利用率が低い、という点については、あんまり驚いていません。Python は日本では普及していないけど (Ruby があるからね)、欧米ではかなり普及してるし。しかし Rails ってのは Ruby on Rails のことだと思うけど、大健闘ですなぁ。。。やっぱりこれからは動作効率ではなくて開発効率の時代なんだなぁ。ってそりゃ前からか。