Category Archives: Mayaa

Mayaaの生まれた日から現在までのWebのフロント開発における時代背景の変化を振り返る

Mayaaの歴史とWebの歴史

今日は、そもそものMayaaの存在意義を過去から未来に向けて探るため、Mayaaが生まれた時代背景を振り返ってみたいと思います。

Mayaaが誕生した時期のWebの状況

Mayaaは2005年のIPA未踏ソフトウェア創造事業に採択されています
公式ドキュメントによると

Mayaaは、すでに2004年11月より、開発がスタートしています。事業に応募した2005年3月現在でも、一通りのコンセプトを実装したプロトタイプ製品がリリース直前の状態ではありました。

とあるので、コンセプト部分は2004年～2005年に生まれたことになります。

当時の言語・ライブラリ・フレームワーク・ミドルウェア・ソフトウェアの最新版はこんな感じです

名前	バージョン
J2SE	5.0
J2EE	1.4
Tomcat	5.5.x
Struts	1.2.x
IE	6 SP2
Firefox	1.0
PHP	5.0.0
Ruby	1.8.2
Ruby on Rails	1.0より前のバージョン

Googleマップのリリースとともに、「Ajax」という単語が生まれたのがちょうどその時（2005年2月）で、まだPrototype.jsやjQueryとかはありません。

WebレイアウトはCSS2はありますが、まだtableレイアウトも使われていた時期です。

そんな時期から、デザイナーとプログラマーの分業の需要があったのはちょっと驚きです。

Web2.0という言葉が出てきたのもこの時期です。

僕がMayaaを使い始めた時のWebの状況

僕が初めて触ったのは2009年8月です。その直前にWicketブームなんてのがあり、Webの開発スタイルがStrutsから大きくシフトしようとしていた時期でもあります。

当時は既にjQueryも存在し、Ajaxも一般的に使われ始めていました。モダンブラウザも生まれていましたが、IE6対応が必須の時代でした。HTML5は草案が出たばかりで、これからという感じでした。

iPhoneは3GS、AndroidはHT-03Aが発売したばかりでした。

Mayaa自体は既に成熟期に入っており、大きな変更はありませんでした。

つまり、Web2.0期の発祥とともに開発が始まり、モバイル時代に入る前に成熟期に入っていたMayaaを僕は使い始めたのでした。

運が良かったと思います。劇的な変更がほとんどなかったので、開発中のシステムをMayaaの最新バージョンに追従していくことが容易でした。

スマートフォン対応・HTML5の時に、nekoHTMLパーサーをビルドしなおさなければならなかったことはありますが、Mayaaは設計が良いのか、現在まで大きな問題なく使えています。

なお、ThymeleafやMixer2はこの後登場します。

現在のWebの状況

2013年くらいに、Webのフロントの世界に激震があり、Angular.jsなど、SPAの技術が旧発展します。

node.jsの発展ともにnpmなどのエコシステムも充実し始め、Grunt / Yeoman / Bower などもあって非常にキラキラしたフロントエンド時代が到来していました。

こうなってくると、サーバーサイドの仕事は、減ってきます。極端な話JSONを返せば良いこともあります！

ただ、SEOが必要な場合、SPAにすることは出来ませんので、サーバーサイドがHTMLを生成する需要は未だにあります。しかし、それで吐き出されたページはBootstrapが入っていたり、だいぶキラキラしていて、そこから先にAjaxを平然と行ったりします。

そして、今年、Mayaaの参加する、Seasarプロジェクトが来年で終了することがアナウンスされました。（Mayaaは今後もメンテナンスを続けます）

未来の予想

Webは混沌としていると言われます。でも、それは、需要がますます高まり、多くのプレイヤーが入り乱れているということも意味しています。

SEO全盛が終わり、IoTやオムニチャネルの時代になってくると、サーバーサイドテンプレートエンジンの技術は必要性が薄れて行くでしょう。

テンプレートというUIよりも、UXの設計が重要と言われますが、ますます顕著になるでしょう。

あと、1,2年で劇的に変わるかもしれません。

その時、Mayaaは役目を終えるのでしょうか？Mayaaが生まれて既に10年を過ぎますが、ニーズがある限りメンテナンスは続けられます。

まとめ

MayaaはいわゆるWeb2.0期に誕生し、Web全盛時代を生き抜きました！今でも十分問題なく使えます！この時代、人々はPCやスマートフォンのブラウザを使って、コミュニケーションをしてきました。

Mayaaがここまで生きてこられたのは、デザイナーが自由にデザインを作ることを制約しない設計であったことがポイントだったと思います。

僕は、IoTや人工知能の時代になっても、これまで紙だったものがWebに置き換わる需要の方が多いと思っているので、すぐに衰退はしないと思っています。そして、Mayaaが使われている限り、メンテナンスに参加し、情報を発信して行きますので、今後共よろしくお願い致します。

Mayaaの経験を活かして、JSPを注意して使う方法

テンプレートエンジンを比較してみて

前回までに、Mayaa, Mixer2, Thymeleaf, JSFのどれを使うべきかについて結論を出しました。しかし、JSPを使わなければいけないケースもありますし、簡単なプログラムではライブラリを導入せず、さっとJSPだけで済ませたい時もあります。

そんなわけで、これまでの経験を元に、JSPを使う際の注意点を考えてみたいと思います。

JSPでいしがみメソッド

m:id含め、プログラム都合の識別子は常に大文字を使う

プログラムに制御情報を書いてしまうのでこの限りではないですが、せめて見えやすくしたいところです。また、中にごちゃごちゃした式を書いていくのはアレなので、taglibやヘルパー関数にまとめたいです。

僕はJSTLやtaglibは中途半端過ぎて嫌いなので、ヘルパーにまとめます。ヘルパー関数はimport staticを使うのが良いと思います。

m:idのする仕事を4種類に限定する

JSPはなんでも出来てしまいます。それこそ、いきなりスクリプトレットで、プログラムを書いてしまうことも出来ますが、それはやめましょう。Mayaaでのいしがみメソッドで使う4種類の仕事のみをJSPでもやるようにしましょう。

4種類の実装方法はルールに従う

こんな感じでスタイルを統一しましょう。

HERE:

名前: <%= escape(bean.getName()) %>

IF:

<% if (bean.isHoge()) { %>
<div>
    ほげほげです。
</div>
<% } %>

TAG:

<a
  href="<%= adjustPath(bean.getUrl()) %>"
>リンク</a>

LOOP:

<% for (int i = 0; i < bean.getSize(); i++) { %>
<div>
    <%= i %>回目のほげほげです。
</div>
<% } %>

LOOP系のm:idはindexには長い名前を使い、maxを十分に大きな値を設定する

これはケースバイケースで考えてください。あまり長い名前にすると、テンプレートが見づらくなりますが、iとかjにすると、ブロックを移動した時に動かなくなるかもしれません。

writeプロセッサーでエスケープを解除するときは全部する

escapeヘルパー関数を作ると良いです。

tableタグだけは特別に扱う

ここは心配がいらないです。

m:idをパラメータ対応にする

これも心配がいらないです。
適宜ヘルパー関数をパラメータ化するのが良いと思います。

PathAdjusterを効果的に使う

ここが意味することは、PathAdjusterみたいなものをヘルパー関数として作ると良いことがあります。JSPテンプレートにベタに絶対パスを調整するコードを書かず常に adjustPath(～) のように囲っておくと、後々良いことがあるはずです。

ヘッダー・フッター・共通部品はiframeタグをうまく使う

<jsp:include>タグを使うのが良いと思います。<%@ include file="" %>ディレクティブを使うべきケースはほぼないと思います。

テンプレート上のコメントは、ソース表示時に見えないようにする

<%-- --%>を使いましょう。

単語はなるべくテンプレート側に書く

これは正反対になります。
単語はテンプレートに書いてはいけません。
どこかのファイルにテーブル化しておくべきです。

nekoHTMLパーサーをいじる

パーサもへったくれもないので、気をつけてValidなHTMLを書いてください。出力したページをバリデータにかけても良いかもしれません。

まとめ

以上、見てみると、意外と、Mayaaでの経験がそのままJSPで活かせそうです。JSPを注意して使うことによって、テンプレートがスパゲッティにならないですみます。

ただ、そう思って自分もJSPを扱っていますが、それでもやはり、JSPはぐちゃぐちゃでデザイナーには読めないものになってしまいますし、常にヘルパー関数を使うようなルールを運用するのはめんどくさく、結局Mayaaを使ったほうが楽だったのではないかと感じてしまうことが多いです。パフォーマンスも良くありません。

ある程度の規模のプログラムを作るときは、JSPは避けるべきだと思います。

テンプレートエンジン（Mayaa, Mixer2, Thymeleaf, JSF2.x）を比較してみて

テンプレートエンジンを比較してみて

昨日までの3回に渡って色々なテンプレートエンジンを試してみました。

ためしてみることで、それぞれの特徴がわかりました。
マトリックスにしてみるとこんな感じです。

名前	独立性	パフォーマンス	デザインフレンドリー	手軽さ
Mayaa	△ (Servlet依存)	△	◎	△ (Mayaaファイル作成が必要)
Mixer2	◎	？ JAXB次第	○	△
Thymeleaf	◎	◎ Velocityより速いらしい	△	◎
JSF2.0 Facelets	△	？	×	○

それぞれの特長

Mayaa

特長

デザイナーとの協業の追求については、一日の長がある
とにかくそれ専用として設計されているため機能が充実している
ドキュメントや実績が豊富

このブログのアドベントカレンダーを最初から読んでくだされば、デザイナーとの協業は心配することがないと思います。

欠点

Servletに依存が強い（JSPと同じレイヤーであるため、JSPの置き換えにしかならない）
パフォーマンスが不利であること
HTML5 サポートとうたえていない
- 閉じタグ忘れなどinvalidなHTMLすら扱えるようにするために利用しているnekoHTMLパーサーがHTML5に対応していないため

HTML5問題についてはnekoHTMLをオフにして、XHTMLをテンプレートとして使用すれば他のテンプレートエンジンと同等になるため、実質的に大きく劣っているわけではありません。

他2については設計上の思想から仕方がないところです。

Mixer2

特長

PathAdjusterなどMayaaの影響を受けた機能を備えている
Mayaa同様テンプレートに制御情報を記述させない設計
Java標準のJAXBを利用しているため、独立性が強く
JUnitと親和性が強く、デザインをユニットテストできる

欠点

制御情報をJavaで書かなければならないためコード量が多い
同じid属性を使用するため、デザイナーとプログラマーが同時に使わなければならない

Thymeleaf

特長

m:idをいちいち定義せずすぐに使える
依存性が低く単独でも動作する
Spring Bootなどに標準対応している
パフォーマンスが良い

欠点

テンプレートに制御情報の記述が必要

JSF2.x Facelets

特長

Java標準であること

欠点

完全な意味での、プログラマー・デザイナーの協業は達成できない

どのテンプレートエンジンを使うべきか

以上を踏まえて考えると、僕は次のように思います。

Mayaaが向いているプロジェクトではMayaaを使うべき

Mayaaが向いている案件とは、

一つの機能に対して、非常に頻繁にデザインの書き換えを行う
または、非常に沢山のバリエーションを作る
コンシューマー向けでデザインを重視したサイト
SEOが必要でサーバーサイドテンプレートエンジンが必要

詳しくは8日目も参考にしてください。

SEOが不要であれば、SPAにしてしまうことも選択肢の一つ

SEOが不要であれば、サーバーサイドはJSONだけを吐き出せば良く、フロント側はBackbone.jsやAngularJS、React.jsを使うという作戦も検討の余地があります。

CRUDを作るとき、AngularJSは非常に手っ取り早いです。Angularではjsファイルを使いまわして、HTMLファイルを複数作るなんてことも出来ます。

コンシューマー向けではない場合は、JSF / Thymeleaf が選択候補に上がる

フレームワークに何を使うかで判断が分かれると思います。
Java EEの時はJSF, Springの時はThymeleafが良いと思います。

デザイン重視ではあるが、多くのバリエーションを作成しない場合は、Thymeleafが有力

デザインのバリエーションを並立する場合、制御情報のコピペが発生してしまうことが懸念点であるので、Thymeleafはデメリットが出てきますが、変更であれば、その問題がありません。

費用対効果を考えた上で、デザイナーを自立させるよりも、プログラマーとデザイナーが都度協力したほうが良い判断であれば、MayaaよりもThymeleafの方が向いています。

デザインをJUnitでテストしたい時は、Mixer2しかない

現状、ユニットテスト可能な唯一のテンプレートエンジンがMixer2です。
そのため、むしろ、機能の変更が頻繁に発生するときに威力を発揮するかもしれません。
機能の変更に対するデザインへのリグレッションテストが自動でできるのはMixer2だけです。

まとめ

このように、それぞれのテンプレートエンジンは、ターゲットとしている問題が微妙に違っていて、それぞれのニーズがあるかぎり、どれかがどれかを排除してしまうことはないものです。

プロジェクトを開始する際にどのテンプレートエンジンを使えばよいか、そのプロジェクトの性格から判断するべきです。

その時、この記事が参考になれば、幸いです。