サーバサイドJavascriptといえば、今一番熱いといわれているnode.jsです。それに関して情報がほしいと思い"サーバサイドJavascript入門"を手に取ったのですが、自分の知識の無さを改めて知ることが出来ました。

趣味でブラウザ上で動くJavascriptサンプルを書いていても、Javascriptを仕事で使うことも、サーバサイドJavascriptを使ったこともほとんどありません(node.jsで少し遊んだ程度)。このため、ブラウザに依存しないJavascriptライブラリがnode.js以外にたくさんあることを知りませんでした。また、サーバサイドJavascriptのためのCommonJSに関する情報もようやく理解できました(名称自体は知っていたが、それがどの程度重要なのかわからなかった)。

WebブラウザJavascriptプラットフォームとnode.js以外で、Javascriptがこれほど広がっているのかと驚きました(ただし、ほとんどマイナーですが...)。本書ではサーバサイドJavascript活用方法なども記載されていますが、それ以外の箇所は、私にとって非常に有益でした(本書で詳細に説明しているサーバサイドJavascriptを使う予定ではなかったので...)。

私はChromeの拡張機能、Google Mapsを使った地震分布、N-Bodyシミュレーションなどを書いていますが、一番Javascriptに不満なのことは、外部サーバへの接続(XMLHttpRequest )やファイルを読み・書き出来ないことです(書くほうはDBあるから良いんだけど、ソース側で勝手にファイル読めない)。セキュリティのために制限をかけていますが、これがブラウザJavascriptプラットフォームとして限界のように見えます。

これらの問題を解決するのが、CommonJSになります。

ブラウザJavascriptプラットフォームとサーバサイドJavascriptプラットフォームを比べていると一番違和感を覚えるのは、ブラウザ上Javascriptプラットフォームをクライアントを評するところです(このような書き方は一般的で通常認識)。ブラウザJavascriptプラットフォームは制限が多すぎます。CommonJS対応プラットフォームが、サーバサイドと評すると一般ユーザには不要なように思えます。

HPがWebOSでnode.jsを採用しました。node.jsを使用すると言ってもサーバサイド的な利用方法でないはずです。スマートフォン・メディアタブレットでサーバサイド的な利用方法はありえません。当然、クライアント的な利用法(CommonJSベースのクライアント?)だと思われます。Rhino等でJavascriptをコンソールから活用できることを考えるとクライアントJavascriptは、ブラウザ上プラットフォームではなくて、もっと別のシーンがあるように思えます。

そういった意味では、WebOS(とnode.js)はJavascriptを再度見直す契機になるのではないかと考えています。

また、Chromeを代表とするJavascript拡張機能も本当のクライアントJavascriptプラットフォームのように思えます(Web Storeで販売されている拡張機能ベースのアプリなど)。ブラウザよりも緩い制限のおかげで自由度は高くなっています。

このため、ブラウザではないクライアントJavascriptプラットフォームが出てきても面白いと思っています。UI部分はWebkit(HTML&CSS)を活用すれば、より簡単に出すことが出来ると思います(これをWeb Storeやガジェットが狙っているのかも知れませんが、そんなに普及が...)。

ブラウザがCommonJSをサポートして、ブラウザベースとクライアントベースを使い分けるシーンが将来的にあっても良そうに思えます。

現在はJavascriptエンジンの高速化の競争は激しいです。v8エンジンの高速化もそうですが、FirefoxやIE、Operaの高速化も目が離すことが出来ません。Javascripは、ブラウザでは非常に重要な言語の地位を確立していますし、node.jsの普及でサーバサイドでも一定のシェアを手に入れるでしょうし、ブラウザ及びサーバサイドで連携しやすいMVCフレームワークが出てくるのではないかと思います(既にあるのかも知れませんが)。

そうなるとぽっかり空いているクライアントアプリプラットフォームとしてJavascript版(CommonJSサポート)が出てきても面白いと思います。CommonJSやWebOSの普及(これが成功するかかなり未知数ではありますが)でJavascriptがまた再度評価を得るときがくるように思えます。