Linux, Apache, MySql, Perl/PHP
私は普段、C#とかWPFとかでWindows業務アプリを主に開発している。私のWebの知識など、10年以上前で止まってしまっている。10年前のWebとはなんだったか。10年前、mixiのベータ版がリリースされた。そのころのWebサービスというのはまだ静的なコンテンツが主だった気がする。その頃のmixiはPerlで実装されていた。自分のTOPページを見るとアドレスがhome.plとなっていた。
PerlとCGIによる実装というのは、昔からLAMP（Linux, Apache, MySql, Perl/PHP）と言われてよく使われてきた方法だ。しかし、現代では素のLAMPというのは生産性が低い。
この頃のWebサービスというのはまだページの遷移が多く伴うようなものだった。クッキーにセッションIDを持たせてサーバー側に状態を持たせる。素のHTTPの仕様ではクライアントの状態によってレスポンスを変化させるということが出来ないことによる、苦肉の策である。苦肉の策であるから、いまだにセッションハイジャック攻撃に利用される。
レガシーなHTTP仕様
そもそも静的なコンテンツの表示しか考慮されていないHTTPの仕様を使って動的なコンテンツを提供するサービスを実装するということ自体が間違っている。そう、間違っている。
しかしそんなことは言わなくとも、Web開発を少しでもやったことがある人だったならば誰しもが知っている。100人に100人が今のHTTPの実装は貧弱で古くて現代的なサービスの構築には適していないと答えるだろう。
HTTPがダメなせいで、いまだに数多くの脆弱性や非効率的な方法が蔓延している。しかし、普通の人にとってはこれはどうしようもなかった。しかし、ここ10年くらいでいくつかのブレイクスルーが発生し、Web開発はずっと良いものになった。
ブレイクスルー
素のLAMPは生産性が低い。HTTP仕様は変えられない。この条件下でいくつかのブレイクスルーがあったからこそ、Web開発は進歩できた。
HTTPの仕様による制限を打ち破ったブレイクスルーのひとつは、Ajaxだろう。代表的なアプリケーションがGoogle MAPだ。それまでの地図表示サービスが八方向の矢印を押してページの遷移を伴って地図をスクロールさせるような方式だったのに対し、Google MAPはページの遷移が無いまま地図をドラッグして自由に移動させることが出来るようになった。これを可能にしたのがJavaScriptだった。
それまでもJavaScriptというのは実装されていたが、その応用例としては、せいぜいステータスバーに時計を表示させるとか、右クリックしたときに「右クリック禁止！」とかうざったいポップアップを出すとか、そういうふうに一部の人間が悦に浸るために使われているという印象でしかなかった。
しかし、ページの遷移を伴わずに新しいデータを取得するというのはJavaScriptにしか出来ない芸当だった。これをAjaxと呼ぶようになり、さらに、AjaxとJavaScriptをもっとマシに使えるようにしようとして、prototype.jsが開発され、jQueryが開発された。jQueryはずいぶん前からデファクトスタンダードになっている。エンジンの開発も急速に進み、各種ブラウザのJavaScript実行速度も劇的に向上した。ChromeのV8エンジンに至ってはnode.jsとしてサーバサイドへ移植されるまでになった。
LAMPによる開発方法はどうだろうか。これも、もっとマシな開発をするため、JavaやRuby、Pythonを用いたWebフレームワークが登場し、幅を利かせるようになった。さらにはWordpressに代表されるCMSの登場により、プログラミングの知識がなくともWebサービスを構築し、継続的に更新していけるようになった。
ほとんどのWebフレームワークは標準のパッケージマネージャにより、便利なモジュールが常に最新で利用できるようになった。本番サーバーにデプロイするときも、環境を再構築する必要なんて無い。ディレクトリごとコピーするか、コマンド一つでモジュール間の依存関係をすべて解決した実行環境が整うようになった。
さらにはHTML5の登場により、クライアントにストレージとデータベースを持てるようになり、サーバと直に通信するコネクションを貼れるようになった。さらにさらに重要なことは、これらの方法を利用するために、TCP/IPの知識やデータベースの知識なんて要らないことだ。面倒くさい作業はぜーんぶフレームワーク・ライブラリ群がラップして隠蔽してくれる。我々が書くのはたった数行のコードで良いのだ。
なぜWeb開発が発展したか
HTTPはダメな子だった。LAMPは生産性が低かった。だから、これらに見切りを付けて、新しい方法を考えても良かったはずだ。たとえば、データと表示を完全に切り離したモデルを考案して、それを全く新しいソフトウェアで実装する。つまり、ApacheとInternet Explorerを置き換えるソフトウェアを作る。そうすれば今のHTTPとWebよりはずっと良い世界が待っていただろう。
じゃあなぜそれを誰もやらなかったのだろうか。やらなかったのではなく、出来なかったのだ。HTTPはあらゆるところで利用されていた。ほぼすべてのパソコンにはInternet Explorerがインストールされていたし、ほぼすべてのWebサーバーではApacheが利用されていた。HTTP通信を行える組み込み型のデバイスが増えた。物やソフトだけでない。HTTPを理解することがスキルになった。スキルを持った技術者が増えれば資産になる。HTTPは世界標準だ。世界中のハード、ソフト、スキルの財産をまるきり捨てて、新しい仕様を策定するのはとんでもなく難しい。
ダメな子を育てて、なんとか一人前にする作業はとても大変だった。けれども、数多のエンジニアが協力してそれを成し遂げた。これは、前述のように既存の資産を捨てきれなかったからだ。より良い言い方をするのであれば、実現不可能な理想論を追い求めるのではなく、皆が現実を見据えて現実に最も則した最も適切な手法を開発し続けた成果である、と言える。
数が正義
重要なのは、最初にHTTPが流行っていなければ、HTML、LAMPが流行っていなければ、こういう結果にはならなかっただろう。もし黎明期に同じような技術があれば、ユーザーが分散して第三のオプションが提案されたかもしれない。けれども当時はそういうものはなかったから、HTTP、HTMLは標準的な技術として受けれられて広まった。それに付随するLAMPアーキテクチャもデファクトスタンダードに近かった。
だからこそ、みんなHTTPをいい子に育てようと頑張った。その道は半ばだが、今後もしばらくはそれが続くだろう。GoogleのSPDYがもっと浸透したら、その次の次くらいにはHTTPヘッダがなくなるかもしれない。
侵食
この数の正義はクライアントサイドまで広がった。FireFox OSではHTML 5によるアプリの開発が標準となっているし、MicrosoftもWindows ストアアプリでついにJavaScriptによる開発をスタートさせた。この流れはもはや止めようが無いだろう。
かつてクライアントサイドで動作していたプログラムはみんなクラウドの名のものとにネットワーク上からサービスを展開させる。サービスを提供する側は、クライアントサイドの環境を考慮しなければならない場面はずっと減る。自動アップデート処理なんて書く必要すらない。
冒頭に書いたように、私は普段、C#とかWPFとかでWindows業務アプリを主に開発している。業務アプリでは未だにWindows forms、下手をするとMFCなんて選択肢もあったりするくらいだ。でも、これらで出来ることのほとんどすべては、おそらく、ブラウザ上のアプリケーションでも構築できるだろう。
強いて言えば、大規模で複雑なシステムでは静的型付け言語で組んだほうが良い場面なんかもある。JavaScriptで全部こなすのはムリだろう。こういう場面では従来、Javaが使われてきたが、JavaもOracleに移ったからなのか、よくわからないがとにかく新機能を導入するのに保守的で、ようやくラムダ式が実装されるくらいだ。Java使いの皆さんには申し訳ないが、古臭さが目立ってきた。
が、それにも別の選択肢がある。Javaを使いたくなければScalaやHaskellを使えばいい。唯一の難点は、「そんな難しい言語使えない」というクソ面白くない意見に遭遇することだ。まあ、そういう勉強できないエンジニアはこれからの10年間で淘汰されると思いたい。
ここで重要なのは、HTTP/HTML/JavaScriptという仕組みが、リッチなUIライブラリを持たない言語にもリッチナUIを提供してしまうということそのものだろう。もはや言語なんて関係なくなってきてる。Webがそうさせてしまった。
まとめ
Web開発が快適になったのは、もともとプアだったフレームワークを皆が改善していったから。その気力があったのは絶対的なユーザー数と実装されているシステムが多かったから。Webの世界では常に優れているものが最も多くのユーザーを獲得するというわけではない。数は正義。