アプリなのにアプリっぽくない Web アプリ

(非同期を使わない)HTML ベースの Web アプリってアプリっぽくない場合があって気になってきた。

例えば、メールクライアントでメールを受信する場合、どれだけ受信数が多くてもアプリケーションは見えている。フォルダとかこれまで受信したメールとか、ツールバーとか。Web アプリで画面遷移が必要だと、その処理の重さとかデータ容量とかで『アプリが消える』っていう違和感がある。

デスクトップアプリだと普通なんだけど、Web でも『非同期』でデータを取得する事って今更ながら大事だな、と。頭の中では、『XUL 勉強しろ!』って警鐘が鳴ってるんだけど、いまいち踏み込めてない。HTML ベースの Ajax でもいいんだけど、どうも XUL が気になる。見た目の自由度(D&D とかの IF 周りも)を考えると HTML ベース乃法が便利な気がしないでもないんだけど、なんか気になる。

HTML ベースで一番嫌なのが、『ブラウザ互換』を考える事。いちいちブラウザ別に検証するのが面倒。OS の壁もあるし。UI のリッチさも大事だけど、それ以前にまず『アプリっぽさ』をアピールしたら楽しいかな、と。XUL だと Mozilla 縛りとか XULRunner とかっていう制限事項はあるけど、Mozilla 自体を Web アプリとして見てもらえば問題ないと思う。どうせアプリを立ち上げる時はショートカットダブルクリックが多いだろうし。開発の手間を考えると、Mozilla 1本化で得られるメリットは馬鹿に出来ない気がする。B2C ならともかく、B2B だし。

XUL インターフェースで作ろうとした場合、既存サービスにてこ入れが必要。HTML 出力とデータアクセスがごっちゃになってるから、JS から使えるデータアクセス用のインターフェースが必要になる。いわゆる WebAPI。前にちょっと勘違いして某氏からアドバイスをもらったんだけど、WebAPI てのは不特定多数に公開する事だけが目的じゃなくて、アプリケーション間の結合度にも関係がある。この場合だと、UI(表示と画面操作)とデータアクセス(CRUD)を分離(疎結合)にさせる事が出来る。なので、WebAPI で対応してる範囲内であれば積極的に UI を変更できる。普通のアプリでも設計次第だとは思うんだけど、フレームワーク内に表示処理とデータ処理が同居するってのが一般的だと思う。WebAPI ベースで進めれば、UI と WebAPI を別のモジュールとして SVN とかで管理できるし、リリースでの変な結合具合も無くなる。

実は、これネタとして社内 SNS に書いてたりする。上手い事乗ってくれたら誰かおだててやってもらおうかなと。いや、1から10までネタなんだけど、ね。WebAPI にする事でサーバにどれだけ負担がかかるかとか、実際の開発コスト(対費用効果だっけ?)とか何も考えてないので。仕事として考えるとネタどまりだと思うんだけど、これから何かアプリケーションを作ろうとした時にこういう指針で進めるのは悪くないとは思う。

プロフィール

このブログ記事について

このページは、koshigoeが2006年5月18日 22:24に書いたブログ記事です。

ひとつ前のブログ記事は「「おーぷんぴーねがいい」について」です。

次のブログ記事は「ちょっと分かってきた LGPL」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。