WebSocketが切り開くネイティブアプリとWebアプリの融合、ネイティブアプリのGUIツールキットとしてのHTML

……というネタを思いついたので、既に同じ事を考えている人は沢山いるだろうけど書いておく。

WebSocketについては「Ajaxをより便利にするもの」という見解が多い。確かに通信のオーバーヘッドの削減やクロスドメイン通信が簡単なこと、サーバからのプッシュが可能となる点は魅力的だ。

しかしそれだけだろうか?

プロトコルとしてのWebSocketは「TCP上で任意のデータを送受信する為の汎用プロトコル」と見なせる。これは実は革新的なことで、WebSocketについて押さえておきたいもう一つの視点にまとめられているようにAjaxの枠を越えてWebSocketが使用されるようになる可能性がある。

これは「ブラウザ・サーバ間」だけでなく「ブラウザ・サーバ以外のアプリケーション間」や「アプリケーション同士」、あるいは「組み込み機器同士」の通信にてWebSocketが使われるようになることをも意味する。

確かに革新的だ。しかしそれだけだろうか?

WebSocketはクロスドメイン通信が可能だ。他のサーバとTCP上で自由にデータをやりとりできる。ところで他のサーバはどこにあるのか? ネットワークの向こう側だけか? いや、ブラウザを動かしているデバイス上のサーバにだってアクセスできる。

つまりもしWebSocketで通信できるネイティブアプリをデバイス上で動かしているのなら、ブラウザからWebSocket経由でそのアプリを操作できるのだ。

このアイデアは「奇をてらった新しいもの」ではない。Unixの世界ではクライアント/サーバ・モデルでソフトウェアが実装されることが少なくない。クライアントとサーバの間の通信にはメッセージキューや名前付きパイプも使えるが、現在ではTCP/IPが使われることが多い。

ただクライアントとしてブラウザを使おうとすると、今までは自分のデバイスにWebサーバをインストールしてHTML等のコンテンツを配置し、ブラウザでそのサーバにアクセスした上でCGI/FCGI経由で通信するしかなかった。これがWebSocketの登場によりUnixのクライアント/サーバ・モデルで済むようになった──WebSocket上に流すプロトコルを決めて、サーバ側のアプリを書くだけだ。幸いにもJettylibwebsocketsといったWebSocketのサーバ側としてアプリに組み込むことが可能なライブラリが出てきている。

では、ブラウザからWebSocketでネイティブアプリを操作できるようになると何が起こるだろうか?

ネイティブアプリとWebアプリの融合

1つの可能性はネイティブアプリとWebアプリの融合だ。

HTML5の登場によってWebブラウザ上で実現できることは増えたが、依然としてネイティブアプリの方が向いているか又はネイティブアプリでしか実現できないこともある。ブラウザからは使用できないOSの機能もあるし、高速化されたとはいえJavaScriptではネイティブアプリよりも遅くなってしまうこともある。

HTML6やHTML7にてHTMLで実現できることを更に増やす、という選択肢もあるだろう。JavaScriptの更なる高速化も進むはずだ。しかしWebSocketを使えばWebアプリ側で実現できない機能をネイティブアプリで実現するという選択も生まれる。Webアプリの欠損をネイティブアプリで埋める、もしくはネイティブアプリの欠損をWebアプリで埋める、というアイデアだ。WebSocketは双方を糊付けするグルーレイヤーの土台となるだろう。

例えば写真共有サイトやお絵描きサイトで利用できる画像編集やドローの機能は結構良くできているのだけど、中には「今まで利用してきた編集ツール(ネイティブアプリ)を使いたい」とか「付属の編集機能では満足できない」という人もいるだろう。

現状では、好きな編集ツールを使いたいなら「画像ファイルを一旦ダウンロードし、編集し、アップロードする」という手間が発生する。面倒だ。あるいは共有サイトの運営側が複数の編集機能をサポートするという手もあるが、コストの面で難しいだろう。

これがWebSocketを使うとどうなるか? 共有サイトで編集したい画像を選択すると、ネイティブアプリの編集ツールが起動するだろう。そして編集後に保存ボタンを押すと編集された画像がブラウザ経由で自動的にアップロードされるのだ*1

WebSocketを使ってWebアプリとネイティブアプリを橋渡しする──この行き着く先は双方の融合だ。両者の垣根は見えにくくなっていくのではないだろうか?

ネイティブアプリのGUIツールキットとしてのHTML

もう1つの可能性として、ネイティブアプリ用のGUIツールキットとしてHTMLが使われる機会が生まれるかもしれない。

WebSocket経由でブラウザからネイティブアプリを操作できるのなら、例えばネイティブアプリをコンソールアプリのデーモンとして実装し、クライアントサイドの技術(HTML5 + JavaScript + jQuery等のライブラリ)でGUIを構築してブラウザから操作しても問題ない。Web管理コンソールのような機能をローカル上で、Webサーバ無しで実現するのだ。

この方法にメリットはあるだろうか? 1つは異なるOS上で単一のコードでGUIを構築できることだ。もう1つはWebアプリケーション開発のフロントエンド分野の各種リソース(ノウハウや既存のライブラリ、はたまたノウハウを持ったプログラマなど)をネイティブアプリの分野に流用できることだ。

ネイティブアプリのGUIは、移植性を確保しにくいパーツの一種だ。OSネイティブのGUIツールキットは当然ながらOSごとに異なる。Windowsでは「.NETの言語 + Windows Forms or WPF」や「C++ + MFC」といった組み合わせがある。Mac OS Xでは「Objective-C + Cocoa AppKit」だろうか。LinuxFreeBSDでは複数の選択肢がある。

移植性のあるGUIツールキットは幾つか存在するが、ライセンス絡みで微妙に手を出しにくい事情を抱えていたり開発元が混乱気味だったり機能やルック&フィールに過不足があったり、なかなか決定打が出にくい。JavaC#(.NETとMonoを併用)という選択もあるが言語が限定されてしまう。

HTMLはどうだろうか? HTMLはOSにはほとんど影響されない。全て同じコードで動作する。影響が出るのはブラウザの違いだが、今ではそれを吸収する為のノウハウやライブラリが蓄積されてきている。ルック&フィールの問題も少ないだろう──今では誰もがWebアプリを使っているのだから。

HTMLならWebアプリのクライアント側の開発の多くを流用できる。大きな違いはAjaxできない点だが、問題にはならないだろう。クライアント側となるコンテンツは何処かのサーバで公開してもよいし、または自分のデバイスのローカルディスクに置いても構わない。ローカルディスクに置くのならWebサーバは不要だ。

HTMLはGUIを担当する。コアの機能はGUIを持たないアプリとして実装してしまえばよい。コンパクトになる分だけ開発やテストの難易度は若干低くなるかもしれない。またクライアント側とサーバ側に分かれることで、テスト時のドライバ/スタブへのすげ替えが楽になるだろう。

ネイティブアプリのGUIとしてHTMLを使うというアイデアは、 SambaのSWATのようなWeb管理コンソールと今は廃れてしまったWindowsのHTML Application(HTA)の合の子みたいなものだ。HTAではWshScriptExecオブジェクトを使って標準入出力経由で他のアプリと通信することができた。WebSocketではHTAがブラウザ上のHTMLとなり、ActiveXを使った標準入出力経由の通信がWebSocketによる通信となる。

もちろん欠点もある。アプリを2つに分離して相互に通信するように設計・実装するのは手間だし、プロセス間通信はプロセス内部でデータをやりとりするよりもコストが高い*2。それにHTMLやJavaScriptのコードが丸見えになってしまう(それどころか、ローカルディスク上の置くのならユーザが好き勝手改造できてしまう)ことが問題となる可能性もある。

まとめ

WebSocketはWebアプリとネイティブアプリの間のグルーレイヤーの土台となる可能性がある。そうなればWebアプリとネイティブアプリの垣根が低くなり、相互に補完しあう関係となりうる。両者の境目が曖昧となるだろう。

またWebSocketを使ったクライアント/サーバ・モデルのアプリケーションは、ネイティブアプリのGUIツールキットとしてのHTMLというあり方を提示するだろう。

*1:ブラウザ経由でアップロードする理由は、ブラウザ側にてユーザがログインしているはずなので、アップロード時に改めて認証する必要がないからだ。

*2:微々たるものかもしれないが、塵も積もれば山となる。