Webフレームワークについては、Javaを使っていたころは(いまでも仕事はJava ! )、
JSP+Servletという仕組みに独自のフレームワークを作って開発していました。
TOMCATを使い始めた2000年には、Webフレームワーク自身が存在していません。
Struts1.0 が、Craig R.McClanahanによって2000年5月に開始され 2001年7月にリリースですから。
TOMCATのJSP仕様書にTaglibの記述ありましたから、TOMCATの開発者はStrutsを意識していたのでしょう。
しかし、StrutsのMVCモデルはいいとして独自のフレームワークを捨ててStrutsを採用する気にはなりませんでした。
- なんで、プログラム開発するのにXMLなの?
- ネーミングルールでモデルが関係されるとEclipsでソースコードで関数追跡できない。
- HTMLやJavaScriptを覚えれるだけでも大変なのにTaglibを覚えるの。
- スクラッチからの開発は素晴らしいけど、いったん画面遷移や仕様変更されると結局作り直し。
Webフレームワーク
それから10年、世の中にはいろいろなWebフレームワークがリリースされ、比較サイトには独自の尺度でランキングしています。
最近の流行は、Spring MVC, GWT, Ruby on Rails, Wicket のようです。
Struts2やSAStrutsもありますね。
Scalaでは、Liftが実績からダントツですが、scalatra、sweetscala、Bowlerなど新興フレームも元気な感じです。
ここでもLiftを評価し、Spring MVC も Java 言語開発の観点から評価してました。
先日も Apache Wicket を見ていたのですが、いまさらJavaかなとも思うしHTMLページ単位にクラスを作るという制約?!や相変わらず Taglib のような独自タグから脱却できない仕様にがっかり。
Liftは、HTML以外のタグを排除するという仕様に感動。
でも、Scalaクラスのプログラムが私のScalaの理解度では何を書いていいのかが直感的にわからない。
lazy val の遅延評価の価値がいまいちピンときていないからでしょう。
JettyじゃなくてやっぱりTOMCATが使いたい。
進む道とは、
これまでのプログラム経験から悟ったことは、
Simple is best
それはシステムがトラブルしているときに、
- 怒っているお客さん。
- 何とかしてと懇願するお客さん。
- もうお出入り禁止と言い放つお客さん。
を前にして、他人の書いたプログラムを追跡して、原因を調べ、パッチを当てるという作業サイクルでは、いくらエレガントな仕様も理解できなきゃどうにもならないということからです。
自分で設計してプログラムを書けば、ブラックボックスはない。
MS-DOSやUNIXのC言語で開発していたころは標準ライブラリしかなかったですから。
でも、JavaEEでビジネスシステムをガンガン開発していたエンジニアや、有名な日本のWebフレームワークの開発者が
「もう、フレームワークの時代ではない」
というブログを読むととっても悲しい気分です。
ということで、軽量Webフレームワークを3日で作ろうというプロジェクト、というより企画です。
Scala (Java) とHTMLだけ。
HTMLは、Webデザイナのお仕事として完全おまかせ。
開発者は、動的Webページに必要な機能を定義して、そのパーツはひたすらScalaかJavaで書けばよし。
という仕様です。
Ruby on Railsのキャッチフレーズが、
- フルスタックなWebフレームワーク
- CoCというシンプルな設計思想
- RJBを使うと、Ajaxと親和性が高い
- RestfulなWebフレームワーク
なら、こちらは、Webフレームワークの中身が完全理解できる というのがキャッチです。
まずは、TOMCATとScalaの結合から。