IEの圧勝で既に決着がついていたかに見えたブラウザ戦争ですが、
ここに来て再びシェアの多様化が起き始めているように感じます。
IEのセキュリティ問題に端を発してのこととは思いますが、最近
ではFirefoxやOperaのシェアが徐々に増加しているようです。
IEのシェアは98%程度だと言われますが、地域によっては(特にMS
に対して何かと厳しい欧州では)80%台にまで落ち込んでいるケー
スもあるようです。
ここで問題になるのはWEBアプリケーション開発ベンダーとして
どういった選択を取るべきか？ということです。気の利いたUIを
実現しようとすれば、どうしてもブラウザ依存したJavaScript
コードを書かざるを得ません。そうなると複数のブラウザに対応
させることは高いコストを伴います。VS.NETなどのIDEや開発ツ
ールを利用してGUIを生成している場合は尚更で、技術的な困難
も伴ってきます。
少なくとも日本に関して言えば、現段階で慌ててIE以外のブラウザ
への対応を焦る必要はないとは思います。ですが、ブラウザシェア
の変動は過去の歴史を振り返る限り、急激かつ急速に起きる性質が
あるようですので何かしらの心構えは必要でしょう。
アプリケーションレベルで取れる対策ということでは抽象的なマー
クアップ言語(おそらくはXML)を導入し、それを変換できるように
しておくことが有効ではないかと思われます。そうしておけば複数
の異なるブラウザへ対応するためにビジネスロジックの変更までも
余儀なくされるといった心配がなくなります。またUIをマークアッ
プ言語レベルで変換するという方式によってモバイル端末などPC以
外の機器へ対応させることも比較的容易になります。
このようにUIコンポーネントとそれが保持するデータ、それを表示
する際に用いるレンダラをそれぞれ分離した設計を持つフレームワ
ークという観点ではやはりJSFが有効です。各UIコンポーネントに
対してブラウザごとのレンダラを用意することによって、各ブラウ
ザ固有の機能を最大限に生かしたアプリケーション開発が可能にな
るのではないかと考えています。
とは言え、実際にやってみるのは大変です。JSFで独自レンダラを
作成するのは簡単とはいえない作業ですし、何しろ作成しなければ
ならないレンダラの数は膨大になります。新しいブラウザが出る度
にそれをやっていたのではコストがかかってしまって困ります。
冷静に考えるとブラウザというのは「HTMLというマークアップを
処理する専用クライアント」だと見なすこともできます。ですので
HTTP越しにインストール/アップデートが手軽にできるモジュール
を配布することができれば、アプリケーション自体をブラウザで
無理に動かす必要もなくなってきます。JavaのJava Web Startや
.NETのClickOnceはそうしたことを目指した試みです。こちらの
アプローチはリッチクライアントとも関連したより抜本的な解決を
目指したものといえるでしょう。
しばらくは上記の2つ、マークアップレベルで対処する方法とクラ
イアントモジュールそのものを見直す方法の両方が並存する状況が
続くと思われます。WEBアプリケーションにおけるクライアントの
在り方については今後も注視していきたいと考えています。
