なぜGWTを使うのか？
私のGWTとの関わり
GWTはグィットと呼ぶらしい、長年の習慣から私はジーダブリュティーと呼んでしまうのだが。かくいう私は、GWTを5年位使ってきた、これは2011年に遡る（途中に使っていない時期もある）。
その頃、ある種の動的なサイトを作成する必要に迫られていたのだが、その当時もはやFlashは今後下火になるだろうと言われており、実際にAppleがFlashをサポートしないと宣言した頃だったと思う。同時にHTML5が喧伝し始められた頃で、今後はFlashのようなプロプライエタリな技術ではなく、HTML5標準の上でのJavaScriptになっていくだろうことが予想された。
しかし、JavaScriptのような、いわゆるスクリプト言語はできれば避けたかった。というのも、（異論のある人もいるだろうが）スクリプト言語は巨大なソフトウェアには対応できないからだ。詳しく言えば、「巨大なソフトウェアで、なおかつ再設計が必要なほどの改変にスクリプト言語は耐えられない」ということ。その当時、一年半以上PHPに苦しめられてきたので、痛いほど身をもって知っていたのだ。
スクリプト言語のプログラムをまともに動作させるには、完全なユニットテストの記述が必要だし、逆に完全なユニットテストを書いてしまうと、大規模な改変は難しくなる。それにともないユニットテストもすべて書き換えなければならないからだ。
一般的にスクリプト言語というのは、メソッド名のスペルミス、引数の型のミス、引数位置のミス、あらゆることで実行時エラーが発生してしまうし、ユニットテストを書く以外に事前にチェックする方法が無い。もちろん、結合テストを除くが。完全な結合テストができるわけでもない。
コンパイラがチェックしてくれるにこしたことはないのだが、なぜ巷ではJavaScriptやらPHPやらRubyなんぞを進んで使おうとするのか、私には全く理解できない。もっとも、このwordpressはPHPやjavaScriptで記述されているが、全くご苦労なことだと思う。これらのひどい言語で途方も無いシステムを作る努力には本当に頭が下がるというものだ。
JavaScriptの代わりの選択肢
そんな努力家でも無いので、代わりの道を探すことにした。つまり、Flashは使わず、JavaScriptは使うが、しかしJavaScriptを書かずに済む方法が無いものかと思案したのである。
そして発見したのが、Closureだった。ちら見した程度でほぼ忘れてしまったのだが、JavaScriptのプリプロセッサのようなものだったと思う。
他の選択肢としては、当時は出ていなかったが、やはりGoogleのDartという言語がある。こちらは、実行環境を何らかの形でブラウザに載せる必要があるので、JavaScriptの代わりとしては使えない。
Closureを調べていたときに、たまたま見つけたのがGWT(Google Web Toolkit)であった。この名前を聞いたときには、「ウェブ開発に便利なライブラリ集なのか」とも思ったのだが、中を見てみるとそうではなかった。中心的な話題としては、Javaで書いたコードをJavaScriptに変換するというものである。
「まさかそんなことが」と最初は信じられなかったものだが。。。。
ともあれ、同じような目的の言語や環境をGoogleは複数出しているのである。つまり、Googleも思っていたということだ「JavaScriptでプログラムを書くなんて」と。でなければ、こんなに様々なプロジェクトは起きない。連中は、JavaScriptみたいな言語を書くのが嫌だったということだ。
ちなみに、現在でもそうなのか知らないが、一時期聞いたことがあるのは、「GoogleにRubyのプロジェクトは存在しない」というものだ。作者が日本人ということで、一時期（今でも？）流行していたのだが、こんなものが未だに使われているのだろうか？疑問ではある。
プログラムというのは、成功すれば巨大になることが宿命付けられている。簡単に書けるからと言って、スクリプト言語で書いてしまえば、そしてそれが成功すれば、徐々に真綿でクビを締められるようにプログラマは苦しみだすのだ。実際に、Rubyでどうしようもなくなったプロジェクトという話も良く聞くところだ。
しかし、このような真実は業界では全く語られない。「Rubyは良い」ということになっているからだ。
GWTとは何か？
さて、GWTは何をしてくれるのか？先に書いたように、「JavaのプログラムをJavaScriptに変換」してくれることである。実際、最初の2,3年はJavaScriptなど一行も書かなかった。すべてJavaで書いたのである。JavaScriptでの記述が必要になってくるのは、GWTで提供されていないブラウザの特別な機能にアクセスする場合とか、あるいは他のJavaScriptファイル(*.js）を呼び出してそれを利用するため位だ。
そして、サーバ側との通信、いわゆるAJAXに必要なことをすべてやってくれることだ。サーバ側は単なるサーブレットなので、もちろんJavaで記述する。
より具体的に言えば、コードは以下のように分割される。
- 1.クライアント側のコード（Java)
- 2.クライアント・サーバ共通のコード（Java）
- 3.サーバ側のコード（Java）
とすべてが、基本的にはJavaで記述される。そして、1.2.はjavaScriptに変換され、クライアント側で使用され、2.3.がサーバ側コードとなる。
2.は共通部でここには、例えば、クライアントとサーバがやり取りするデータを表現するクラス等ということになる。未だに明確な仕組みを理解していないのだが、クライアント側で使われる場合はJavaScriptのオブジェクトとなり、サーバ側で使われる場合はJavaのオブジェクトとなり、その間の変換が自動で行われる。
そして、これらすべてのコードは単一のwarファイルにまとめられる。これを何らかのサーブレットエンジンにデプロイすれば良い。
クライアント側のブラウザは、エントリポイントのページを表示することで、warファイル内に格納されたJavaScriptをロードし、それを実行し、後はサーバとの通信を行って行くという仕組みだ。
ブラウザごとの違い
2011年当時は、まだHTML5の実装がされていなかったため、ブラウザごとにJavaScriptの実装はバラバラな部分があった。
その当時のGWTでは、同じコードを書いてもそれをブラウザごとのふるまいに適合するよう別々のJavaScriptコードを生成するという機能があった、これをpermutationと呼ぶ。
アクセスしてきたブラウザに応じ、そのためのpermutationのJavaScriptコードを返すため、ブラウザの違いを気にすることはほとんど無かった。
しかし、現在はHTML5標準に落ち着いているようで、複数のpermutationの生成の必要も無いようだ。
GWTを利用しているサイトとウィジェット
GWTで作成されている最も有名なサイトと言えば、Google最大のウェブアプリケーションと言われるAdWordsがある。Google Walletもそうだと現在の開発元は主張している。
ただし、見たところGoogle側では、GWT上で動作するようなウィジェットをかなり開発しているようである（そしてこちらは公開されていない）。
GWTを使えば、こういったサイトが作成できると思ってはいけない。GWTにもともと備わっているウィジェットは非常に貧弱なもので、HTMLで書くようなボタンやら入力フィールドやらと同等の機能しかない。
サード・パーティから多くの種類の便利なウィジェットが出されているが、有料で高価であったり、自分の好みに合わなかったりと、これまた選択が難しい。
しかし、基本的なところとしては、今現在のあまた開発されているJavaScriptのライブラリ（特に動的な効果）と同じことができるとは思わない方がよい。エンドユーザ向けのこういった派手な仕掛けは、個人的にはGWTには向いていないと思う。おそらくは、派手な効果を得るだけで苦労することになるだろう。
AdWordsに代表されるような、派手さの無い、ある種無骨な画面、裏方的な仕組みを作り出すのに最も向いていると思われる。