Client Side Java

よくできたAjaxアプリを見慣れてくると、ブラウザで動くスクリプトとしてJavaScript以外の仕組みを使うことはあまり思いつかないかもしれません。ただ、Webアプリケーションの基盤の一部として長い目で見た場合に、いくつか改善の余地があることに気がつきます。

• Javaの場合はsandboxの制限を緩めてローカルリソースにアクセスできますが、JavaScriptでは（独自拡張しないかぎり）できません。
• アプリケーションが大規模になってくると、JavaScriptのコードの量が当然多くなります。しかも、プログラムをバイトコードでなくテキストで HTTP/GET し、クライアントサイドのJavaScriptインタープリタで毎回構文解析をして実行しなければなりません。処理が小さいうちは、一瞬で起動できるインタプリタでスクリプトを実行した方が速いかもしれませんが、大きなアプリケーションでは、構文解析が済んだ状態のバイトコードをダウンロードして実行した方が効率の面で逆転するでしょう。
• prototype.jsのようなベースとなるようなライブラリを、アプリケーション用のスクリプトと同じように扱っていて、（ブラウザがキャッシュしてくれるとはいえ）論理的には毎回取りにいきます。本当は、共有される基本ライブラリは、一度だけダウンロードしておいて、あとはバージョンが新しくならないかぎりダウンロードはしなくて済むようにするべきです。

で、通常はJavaScriptで書くonclick等のイベントハンドラや DOM へのアクセスを Javaで実現するようなブラウザのプラグインは実現できないか、という妄想をしはじめました。起動時間については、Java-pluginと違ってSwing/AWTを使わず、最近のマシンだと0.2秒くらいになるので、Appletのような問題は起きないでしょう。JSR223経由のRhinoを使って、互換性を保ったままJavaScriptの実装を差し替えることができれば、ブラウザ間の非互換性に対する解になるかもしれません（逆に非互換性の元を一つ増やしてしまうかもしれませんが）。Windowsの場合はJREの配布の問題はありますが、上に挙げた問題が解決できるとすれば、それなりに価値はあると思うのです。