はじめに
ここ最近、html5jえんぷら部&JJUG合同勉強会での「HTML5 における Java の役割」とか Developer Summit in Kobe での 「HTML5 と Java」をテーマとしたセッションをいくつか聴講したのでまとめます。Java の方向性としては Scala によるより扱いやすく（開発が容易な）という方向性と JavaScript エンジンを Java に取り込みクライアント＆サーバの開発効率を上げることがあるように感じられます。
フロントエンドエンジニアとしては JavaFX の存在というのは貴重で クライアントで Java の資源を使いながら且つ HTML5 の機能も使えるというのは有用と考えています。これはいわゆるハイブリッドアプリケーションですが、一般には「枠」をネイティブで作り「中身」を HTML5 で作成することでクライアントのリソースも有効に使え且つアプリケーションの再配布を HTML 化することでやはり容易になるというメリットがあります。もちろんデメリットもありますが。業務システムエンジニアとしては、ネイティブで作成するよりも使い慣れた Java でクライアントアプリケーションを作成できるというのはやはり有用であり、そういった意味でも JavaFX には注目していきたいと考えています。
ここでは、HTML5 の登場によりフロント業務アプリケーションがどのように変わっているのかを記したいと考えております。記載内容は実際に私があるプロジェクトで実施している内容です。
注意事項として「フロント」と言った場合「一般的には社内システム全般も含まれます」が、ここでは「営業が客先面前で使用するアプリケーション」を指します。
個人的な考えですが
こういったことが考えられないのであればメリットは無いと考えています。よって、フロントシステムエンジニアは HTML5 を使った新しいビジネスモデルを構築（提案）する必要があるのではないかと思います。
さて、本題に入りたいと思います。
従来型の Web アプリケーション
JSP を用いた Web アプリケーションは
- リクエストをサーバへ送りサーブレットである Controller へ送付する
- Controllerは必要な情報を POJO → Business Logic → O/Rマッパー → Database で取得（登録・更新）する
- ページを jsp で生成しController経由でクライアントへ返却する
- 各ページでは Ajax により部分的な情報の取得を行う
従来型のWebアプリケーション開発では、そのほとんどを「Java」で実装しています。JavaScript での処理は
- 簡単なポップアップ画面ライクな画面表示を行う
- Ajax を利用して情報をその都度取得する
のを目的として使用しています。
最近の Web アプリケーション
最近の Web アプリケーションでどうなったか？従来型 Web アプリケーションとの違いは、ページというものをシングルページで作成（あるいは用途ごとにシングルページ化）し画面の遷移は JavaScript で生成することが大きく異なります。
- HTML で作成された画面を表示
- 必要な情報を REST で取得（登録・更新）し画面へ表示する
- 取得したトランザクション情報を Web Storage へ格納する。マスターは master.js を生成しクライアントへ配置する
- 以後、ページとWeb Storage で情報のやり取りを行う
- 一連の業務完了後、データを REST でサーバへ送信しWeb Storage とサーバの同期を行う
最近の Web アプリケーションでは、そのほとんどを JavaScript で作成しています。Java は「情報を永続化するため」に使用されます。
ここで注意することとして「一連の業務完了」というものが業務アプリケーション毎に異なる点です。在庫管理のような直にサーバに確認したいようなアプリケーションでは頻繁に発生しますが、ライフプランニングのような一日、数日経過しても問題ないようなアプリケーションまで時間枠が異なります。より発揮するのは後者のようなアプリケーションでは、モダン Web アプリケーションの本領発揮と考えています。
Web Storage や Application Cache を使うメリット
Web Storage や Application Cache を使うことで、ページ切り替えリクエストをブラウザ内で処理することができます。従来型ではページ切り替え時の通信時間に、少なくとも 2,3秒要していましたが、この切り替え時間がほとんど要しないで処理が行えます。
これはユーザビリティにとって非常に重要なことです。従来型の Web アプリケーションではもっさりした感覚のあるものがほとんどですが、Web Storage や Application Cache の恩恵により、限りなくファットクライアントに近いリッチクライアントを作ることができます。
開発スタイルがどう変化したか
開発のウェイトが java から JavaScript へ移ったことにより、アプリケーション開発環境も大きく変化しています。従来型では
が主たる開発環境でありましたが、最近の Web アプリケーションでは
での開発が有用です。
yeoman は yeoman.io から引用すると
Yeoman is an open source project which defines an opinionated stack for web application development.
です。
travis は継続的インテグレーションで Jenkins と同じ立ち位置のものです。
当然ですが、サーバサイドのモジュールを開発するときには従来型の開発環境を使います。
開発要員構成
JavaScript での処理が多くなっているため必要とされる開発要員のスキルセットが変化しています。従来型ではそのほとんどが Java エンジニアで
でしたが、現在では
- Javaエンジニア：３名
- JavaScriptエンジニア：２１名
- デザイナー：４名
- 業務コンサルティング：３名
です。これはあるプロジェクトの要員バランスですが Java エンジニアが 1/8 に成ってしまったことはエンジニアにとっては考え深いものがあります。
JavaScript フレームワークの導入
JavaScript でのコーティング量が増加したことにより、実装の整理としてフレームワークの導入が必要になってきます。コーティングルールで実装方法の定義をするよりもフレームワーク導入によるコーティング規制の方が実装束縛があり統一されたものができあがります。
ここは個人的なものですが JavaScript として気に入っているものを上げます
- AngularJS
- Backbone
AngularJS は Googleメンバーにより開発されたフレームワークです。DOM操作を提供するフレームワークではないのですが、静的なHTMLファイルを動的ドキュメントのように扱うことができます。JSPなどのページ生成言語と同じようにHTML内のプレスホルダを置換することで扱っています。
Backbone は多くのプロジェクトで利用されています。データバインディングとカスタムイベントを備えた Model とそのイテレーションである Collection、イベントをハンドリングする View やサーバサイドのアプリケーションと連動するための RESTful JSONなどが提供されます。
Web アプリケーション開発のもうひとつの変化
従来 png で作成していた
- イメージボタン
- div の角を丸める
といったことが CSS3 で作成可能となったことから カスケードスタイルシートのコーティング量が急増しています。そのためデザイナーでもある程度のhtml、CSS実装ができることが要求されています。
開発インフラとしては、例えば
- Sass & Compass
の導入により、より効率のよいアプリケーション開発を行うように成っています。
CoffeeScript の導入メリット
全体像としては Java から JavaScript への開発ウェイトの移動が行われていますが、より重要なこととして「安全な JavaScript モジュールの開発」ということが上げられます。JavaScript嫌いな方から見ると 「JavaScript のいい加減さ」（表現があまりよくありません）が好きになれないと思います。
そうした背景もあり「altJS」でより安全に快適にJavaScript をコーティングするよう変化しています。
CoffeeScript の導入メリットとしては
- コーティング量が少ない
- JavaScript の罠に引っかからない
- 書き方がある程度統一される
ということが上げられています。JavaScript の罠は
- var の書き方（var の書き忘れ）
- this の定義
- return の明確化
等がありますが、こういったことを CoffeeScript がうまく補完してくれています。「コーティング量が」というのはあまり意識したことはないですが「書き方」についてはインデント形式の書き方もあり、だれが書いてもあまり変わらないです。当然ですが、ロジックの記載による個人差はあります。
JavaScript のセキュリティ
JavaScript でのコーティング量が増えたことから JavaScript のセキュリティについてもより多くのことを考える必要があります。
- ロジックをオープンソース化してしまうこと
- Web Storage にある情報が読み取り可能
JavaScript に関しては難読化、情報に関しては暗号化してから Web Storage への保存等考慮すべきことがいくつかあります。
最後に
HTML5 の到来により、今までとは異なるアーキテクチャでの実装が必要となっています。アーキテクチャが変わったことにより実装環境も大きく変える必要が当然あります。いままでの開発スタイルはあくまでも Javaコーティングスタイルに合わせたものですので、これからは JavaScript コーティングスタイルに合った開発環境を作るべきです。
Java は Web アプリケーションとしてのバックエンドの機能（コーティングしやすさを含んだ）を充実させる必要があります。このことは、業務系システムは今すぐ脱Strutsを！」業務システムエンジニアのためのHTML5勉強会#04 活動報告でも寺田氏があげらているように「次世代型WebアプリケーションとJava標準「Java EE 7」」となるところです。個人的には Java の方向性が「正しく」定まっているのではないかと思います。
また JavaScript コーダーが Java コーティングの苦痛から逃れるような対応が必要であり、そのための Scala であり Mixer2 であると考えています。
ここで述べた開発スタイルは、まだエンタープライズでは少数と思います。いずれくるであろう HTML5 時代の準備を今からするのは有効と考えています。
