『実践JSサーバサイドJavaScript入門』――あえてサーバサイドでJavaScriptを使う意義を探る
 |
実践JS サーバサイドJavaScript入門 井上 誠一郎（著） 技術評論社 2011年4月 ISBN-10: 4774146293 ISBN-13: 978-4774146294 3570円（税込） |
■Webブラウザという揺りかごを捨てたJavaScript
JavaScriptを使う理由はただ1つ、他に選択肢がないからだ。JavaScriptは、Webブラウザで動く唯一の言語である。FlashやJavaアプレットでもWebブラウザからプログラムを動かせるが、JavaScriptとは根本的に違う。
- プラグインやJVM（Java仮想マシン）など外部的な何かを必要としない
- HTMLを直接操作できる
この2点において、JavaScriptは圧倒的な優位性がある。他の言語はWebブラウザの世界に入ることすら許されない。
今、Webブラウザの中で育った言語が、サーバサイドJavaScriptという形でWebブラウザから飛び出そうとしている。
しかし、ブラウザ以外でJavaScriptを使う理由はどこにあるのか？ Webブラウザというゆりかごを捨てて他の言語と同じ土俵に立つことで、JavaScriptはどこに向かおうとしているのか。
■概念としてのサーバサイドJS
本書は6章構成である。
- Part1 サーバサイドJavaScript序論
- Part2 共通API
- Part3 サーバサイドJavaScript
- Part4 ドキュメントDB
- Part5 クラウドの拡張言語
- Part6 Webアプリ実装
前半はJavaScriptの歴史、後半はDBの拡張言語としてのJavaScriptや、Javaの話が中心だ。Java Servletだけでなく、DIやRESTの知識、Javaでの使い方を知らないと、読み進めるのは難しい。
現段階では、サーバサイドJavaScriptとは、仕様でも実装でもなく「概念」だ。本書は、単純にサーバサイドで動くだけのライブラリからMVCアーキテクチャを実現するフレームワークまで、有名なライブラリやフレームワークを、サンプルとともに紹介している。技術のTipsというよりは、どちらかといえばJavaScriptを取り巻く“今”を俯瞰（ふかん）するための書物である。
本書を読んでいるうちに、以下の問いが頭をめぐった。
サーバサイドでJavaScriptを動かすことの意義はどこにあるのか？
■クライアント／サーバサイド、すべてをJavaScriptで書く？
Webアプリケーションには、さまざまな言語や技術要素が混在する。クライアント側に出力するHTML、CSS、JavaScriptをサーバサイドの言語で制御するスタイルが一般的だ。
ここに、サーバサイドで動くプログラム言語としてJavaScriptが新たに加わった。「言語の混在を解決する」というが、クライアントとサーバサイドの言語が一致することにどんなメリットがあるのか。
「どうせやるならサーバサイドも含めてすべてJavaScriptで作ろう（p.28）」
本書はこのように提案している。1つの言語だけですべてが成り立つのなら学習コストは下がるが、現実はそう甘くない。
例えば、クライアントサイドの言語としてJavaScriptをゴリゴリと書いたとしても、Webブラウザのみというネイティブな環境だけではJavaScriptは力不足だ。たいていの場合、Webブラウザ間の依存を吸収するためにjQueryやprototype.jsなどのライブラリを使用することになるし、ライブラリを使わなければなおのこと、依存関係を隠ぺいするために何らかの手段を講じなければならない。
私がこのアプローチをとるなら、JavaScriptを自動生成するようなフレームワークやライブラリを採用するだろう。JavaScriptをまったく知らなくてもよいという意味ではないが、適切なものを選択すれば、JavaScriptを書く必要はほとんどない。
GWT（Google Web Toolkit）を使うなら、GWTが出力するJavaScriptをきちんと理解した上でライブラリを使用する。それでも機能が足りないならば、GWTの枠組みの中でJavaScriptを自動生成するプログラムを書く。なぜなら、クライアント側のコードはブラウザによって挙動が違うからだ。Webブラウザごと処理を切り替えるようなロジックをJavaScriptに書くよりは、ブラウザごとに必要なJavaScriptのみを出力させているほうがよい。
本書が例示する「バリデーションコードの重複」などは、サーバサイド言語から自動でJavaScriptを出力させた方が良い。この手の処理は再利用可能な作り方をしているので、正しい使い方を理解していれば何も問題ない。
インフラも含めてWebアプリケーションのアーキテクチャは日々、複雑さを増している。厳しいことを言うようだが、複数の言語が入り乱れた程度で「プログラムが作れない」と音を上げる人間に、今日のWebアプリケーションの開発は不可能だと思う。
事実、最終章ではJavaで構築したアプリの上でJavaのVMを経由してJavaScriptを実装している。これは相当に難しいアーキテクチャである。この場合、言語の差異、つまり「JavaにできてJavaScriptできないこと」と「JavaScriptにできてJavaにできないこと」を明確に知った上での実装を要求される。「クライアントサイド／サーバサイド」という明確な線引きができるようなものではない。
■サーバサイドJSは、ロジックの入れ替えが自由なのか？
「サーバ側に他のプログラミング言語を使う場合に比べて、コードを相互に移動可能だからです。クライアント側が重いとなれば、処理をクライアントからサーバに移す、あるいは逆の移動、このようなことが相対的に容易です（p.30）」
上記の文章は「JavaScriptならクライアントサイド、サーバサイドで相互にコピペで移植が可能」と読める。しかし、この考え方は危険だと私は思う。
プログラムは、動きさえすれば何をやってもよいというものではない。クライアントとサーバでは役割が違う。コードが書かれる場所にはしかるべき理由があり、「どこに書いてもいい」処理は存在しない。
入れ替え可能なロジックはコピペで行うのではなく、プログラムの中で実現するべきものだ。プロキシやアダプタを使い疎結合にして、ストラテジなどのパターンでプログラムを部品化する。その先で負荷分散やパフォーマンスチューニングを行う。最適化はそれぞれの領域が持つ技術で解決したい。
JavaScriptはほんの少しDOM（Document Object Model）への参照に気をつかうだけでも、動作速度がぜんぜん違う。正しい知識を持って作れば、たいていの処理は高速化される。特にサーバサイドでは、負荷分散の技術は山のようにある。そちらの技術を使えばいいのではないだろうか。
小手先のテクニックでごまかしていると、問題が起こった時、真の原因にたどり着けなくなる。ただし、初学者がクライアントとサーバそれぞれの役割を学習するという意味では、有効なアプローチにはなるだろう。
■JavaScriptの未成熟なライブラリ？
「他のプログラミング言語では当たり前にあるようなファイルの読み書きすらJavaScriptの標準APIには存在しない（p.26）」
JavaScriptはその発展の歴史から、Webブラウザが必要としない機能は組み込んでこなかった。Webブラウザから動かすJavaScriptでさえ力不足を感じるときがあるが、その解として、CommonJSを中心とした標準APIとでもいうべきものが策定されようとしている。
標準APIといいつつ、今の段階では仕様が固まっていないものが多い。だが、今後標準APIが大きく変更されることはないだろう。これらは、JavaScriptという処理系に何が足りないのかを明確にしてくれる。言語の外枠が見えてくれば、標準APIがリリースされることを待たなくても、今のJavaScriptの書き方が見えてくるのかもしれない。
基本的な道具がそろっている言語は“成熟している”と言える。だが、JavaScriptはどうだろうか？ おそらく、ここがサーバサイドJavaScriptで最も弱い部分だろう。Javaや.NET Frameworkなど、他言語のライブラリや、オープンソースの充実ぶりを見ているとよく分かる。
流行の負荷分散やパターン認識、自然言語解析だけでなく、ロガー1つ取っても、JavaScriptだけでは心もとない。JavaScriptは、まだまだサーバサイドで使うだけの道具が足りない。使える道具がひととおり揃うまでに数年はかかるだろうと見ている。
プログラム言語は仕様だけがすべてではない。それを取り巻くコミュニティや文化といったものがあって初めて成熟する。見方を変えれば、今サーバサイドJavaScriptの世界に飛び込んでおけば、JavaScriptが真の実力を得たときに、自分が活躍できる日が来るかもしれない。
■じゃじゃ馬のようなJavaScriptをいつか使いこなすために
プログラミング言語は面倒なものである。そもそも、処理系を用意したり、環境を構築したりという、コードを書き始めるまでの準備が面倒だ。画面が派手に動くプログラムを作るのだって難しい。
こうした手間を飛ばしていきなりプログラムが書けて実行できるJavaScriptは貴重な言語である。必要なのはブラウザとテキストエディタだけ。文法を少し覚えたらスグに実行できる。HTMLの知識があれば、GUIでインタラクティブなツールを簡単に作れる。
だが、私は「安易」というイメージのままサーバサイドに持っていくことに警鐘を鳴らしたい。JavaScriptは、お手軽に組める言語であるがプログラム言語としては相当に扱いづらい。奥が深いといってもいいだろう。
『JavaScript The Good Parts』にはこう書かれている。
「JavaScriptには多くの設計ミスと、変わった特徴が存在している」
JavaScriptには、DOM（Document Object Model）を直接操作できることや、関数型言語の性質、それらがオブジェクトの中に取り込めることなどの魅力がある。JavaScriptの持つ真の力を出せるアプリケーションを作るには相当な力量を要求されることになるだろう。あらためて思う。サーバサイドJavaScriptよりもJavaScriptの方が難解だ。
私自身、関数型言語の思想が、まだ本能レベルで理解できていない。ちょうど、手続型言語で育った世代がオブジェクト指向言語に感じる壁のようなものを感じている。それでもエンジニアの矜持として、技術から逃げたくはない。いつの日か、このじゃじゃ馬のような言語を乗りこなしてみたい。
（『フリーなスキル』コラムニスト はがねのつるぎ）