スクリプトレットバッシングの時代にズダボロに引き裂かれたStrutsと、グングン成長したRails

スクリプトレットパッシングの猛吹雪の中にいたのは、Struts(JSP)だけではない。
Rails(eRuby)もいた、そしてRailsは、バッシングをくぐり抜けた。
過酷な時代だった。

スクリプトレットで、メンテ不能になったJSPが、世間にあふれたことで、開発者は、JSPを信用しなくなり、HTMLベースのテンプレートエンジンがもてはやされた。

問題は、スクリプトレットに何でもロジックを書いてしまうという、開発者の姿勢なのに、なぜか、みんな、JSPまで否定してしまった。

つまり、このJSPへの過度なバッシングは、単なる不運ではなく人災だった。
「誰の責任でもない」というのは嘘だ。
この惨劇の責任を負うべき人たちは、たしかにいる。

Javaの世界も例外ではなかった。

叩かれるのを承知で正直に告白すると、ぼくは、いつもろくにJSPは使わずに、HTMLベースのテンプレートエンジンを開発していた。僕のHTMLテンプレートエンジンに対するノウハウはグングン伸びていった。それに比例して、はぶさんの体重も肥え太った。

Railsも要領よくババを交わした。
すべてRubyで記述することがいいことなんだという方針を打ち出すことで、
スクリプトレットを善に変えてしまった。

あれから、4年がたった。HTMLベースのテンプレートエンジンのノウハウもたまり、その長所も短所も見えるようになってきた。
今から思うと、JSPは過剰にバッシングされてきた。その原因の一端は、ほかならぬ私自身にある。

きれいなHTML(Viewテンプレート)が、重要だという気持ちは、今も変わらない。ただし、きれいなHTMLがコストを生むことも十分に理解できた。
コストというのは、Teedaにおける規約だったり、他のフレームワークにおけるView用の設定ファイルなどだ。

今の私がしなければいけないことは、HTMLベースのテンプレートエンジンのメリット・デメリットをきちんと明らかにして、人々が選択する際の情報を増やすことだろう。
また、JSPに対する誤解をきちんと解くことだろう。

JSPは、きれいなHTMLが、それほど重要でない局面では、多分一番よい選択肢だと思う。
ELやファンクションを組み合わせると、すごく手軽にサーバサイドの情報をViewの中に埋め込める。パフォーマンスは良いし、いざとなれば、スクリプトレットもかける。

スクリプトレットはJSPに直接記述できる手軽なファンクションとして使えば、JSPがスパゲティーになる危険は少ない。
下記のエントリも参考になると思う。

<%

public static <T> T getComponent(final Class<T> componentClass) {

    return (T) SingletonS2Container.getComponent(componentClass);

}

%>

<%

for (Employee e : getComponent(EmployeeAction.class).empItems) {

    out.println(e.name);

}

%>

追記:パッシングじゃなくて、バッシングですね。修正しました。

追記2:スクリプレットじゃなくて、スクリプトレットですね。修正しました。