2003-12-07

近況

アップルストアを見にくる人も, 実物を買うのは近所のヨドバシなんだろうね. ポイントもつくし. などと下々な会話をしつつ到着した人混みで見たものは, 発注カウンターに群がる人々の姿だった. そんな世界に住む者の心を捉えるのは, たとえば親馬鹿風に捏造されたサンプル旅行記動画だったりして, 構図が退屈な割に手ぶれしないカメラや不自然なほど自然に振舞う子供達や妻の姿が私の心をうつ. それに心魅かれる無邪気さを馬鹿にできたら幸せだと思う.

HTML の利点と問題点 : 糊, アニメーション, ネットワーク

(つづきものです.) HTML はもともと先の条件 (サードパーティのオーサリングツール使える, オーサリングツールなしでも使える) を満たしていた. つまり 1. photoshop などのサードパーティ製ツールでアイコンや GUI 部品をつくり, 2. テキストエディタでそれらを並べる 方式. 古典的な HTML コンテンツはこうして作った. このとき HTML は文書のマークアップである他に glue language として振舞っている.

JavaScript と DOM の登場によって 画面の構成要素を動かせるようになると HTML の中にコンテンツ (JavaScript アニメーション) が入りこみ, HTML=glue という役割分担が崩れる. HTML はもともと 静的な文書を記述するためのもので, 動的なアニメーションは得意でない. その上プログラムでアニメーションを書くのは, プログラマにとってもしんどい作業である. (HTML が文書のレイアウトをスクリプトで指定するものだったら普及しただろうかと想像しよう.) FLASH はネイティブにアニメーションをサポートしているから, 無理なくそれを実現できる. 結局, HTML にとっては無理にアニメーションを実現してしまったことが FLASH の普及を許したという意味で失敗だった (良いところもある).

また HTML をアプリケーションのプラットホームとして使い始めると, サーバとの通信がなんとも不自由で辟易してしまう. FORM を HTTP で submit するという枠組みが原始的すぎるのだ. 値は key/value でしか渡せないし(あとはせいぜい MIME でファイルをアップロードするくらい), 同期通信だから利用者は通信のあいだ待ちぼうけにあう. スムーズな画面遷移なんてとても期待できない. 文書のマークアップ言語である HTML に高度なネットワーク機能を要求するのが無茶なのはわかる. しかしこの制約は厳しい. HTML が GUI でFLASH に水をあけられたのは, オーサリングのしにくさやレンダリング能力の不足より, この同期通信という制約にあるのではないかと私は思う. プラグインなら画面の反応を保ったまま裏でこっそりサーバと通信できるし, ついでに送信するデータのフォーマットも自由だ.

アニメーションに関して, FLASH の代替をなしとげるのは難しいと思う. というのは, FLASH がもともとそれ=アニメーションを目的としたシステムだから. その優れたアニメーション機能によって FLASH は地位を築いた. FLASH のアニメーション機能について世間の FLASH ユーザがどんな不満を持っているのかわからない以上, 私がその代替についてどうこう言うことはできない. 不満があるようにも見えないし.

もうひとつの不満要素であるネットワーキングについては, なすべきことがあるように思える. HTML ブラウザが提供するネットワーク機能についての不満は, 上でも述べたとおり 1. データモデルが貧弱なこと. 2. 同期通信であること の二点を挙げられる. また, 高度なネットワーキングを利用するのはスクリプトになるわけだが, スクリプティング自身も現状では貧弱. 提供されているライブラリ群が不十分だ.

実のところ上のような機能を実現するのはさほど難しくない. あるいは(情報が少いだけで)ほぼ実現されている: Internet Explorer には COM が, Mozilla には XPCOM がある.しかしこれらの仕組みは無制限にシステムを利用できてしまうため, セキュリティ上問題がある. プラグインのような仕組みは, セキュリティを確保するレイヤとして必要だろう. FLASH のネットワーク機能は特筆すべきものではない. ごく普通. FLASH のライバルになるはずだった applet を思いだしてみる. ネットワーキングや programmability という視点からみると, applet はよくできている. ただ, 政治的なあれこれや GUI の弱さによって普及しそこねた. 政治はともかく, GUI について applet と 同じ轍を踏むわけにはいかない. かといってオーサリングツールを作っていたら日が暮れてしまう.

だから, HTML を使おう

なぜなら HTML はもはや最も普及した GUI ツールキットになっており, そのためのオーサリングツールは多く, それに精通したデザイナは山のようにいるから. そして HTML as GUI がもつ不自由さの大半は同期通信モデルに起因していると私は思うからだ.

結局, "不健全 FLASH alternative" 構想はこんな風になる. (このへんからはまったくの妄想なので眉に唾せよ.)

要するに現在サーバサイドでやっていることの一部をクライアント側にもってくればよい. クライアント側の自由度を増やし, ユーザとのインタラクションを強化できる. また, glue-language としての重要な特性である View-Source Transparency が損なわれていない点にも注意してほしい. これは Microsoft の Avalon がやろうとしているアプローチと似ている. 以前リッチクライアントと呼ばれていたアプローチの亜種だ. これをブラウザでなく, HTML のレンダリングエンジンだけを拝借した単体のアプリケーションとして実現してもよい. Macromedia Central もどきができあがる.

このアプローチだと, GUI の自由度は FLASH に及ばない. しかし, 通信のたびに画面を書換えて待たせる現状のウェブよりはだいぶ強力になる. 更に言えば, このアプローチは現状の FLASH と競合しない. なぜなら HTML の中に FLASH を埋めこむことができるから. それに正直なところ, 私は FLASH altenative に FLASH 並の GUI なんて要らないと思っているのだ. 高度なアニメーションや GUI がほんとうに必要なら FLASH を使えばいい. ただ, FLASH の敷居の高さにおじけつつ, 現状の HTML ブラウザのモデルに不満を持っている層 (私はその典型) に使えるプラットホームがあってもよいのではないか. FLASH ユーザの中に優秀な人がいるのは間違いないが, "優秀な開発者は、FLASH にみんな移行してしまった" なんてのは単なる自己卑下であって欲しい. 格好良い UI だけがアプリケーションの良さではないのだから.

つまらない開発者はそんな風に思うのであります.