Scalaのアプリケーションフレームワーク"Lift"　（1: 概説）

Scalaのアプリケーションフレームワーク"Lift"をについて複数回に渡って紹介していこうと思います。
初回はLiftの概要について説明していきます。

Liftとは

LiftはRuby on Rails然なフルスタックアプリケーションフレームワークです。
Scalaのアプリケーションフレームワークと言えば、"Play"が有名ですが、Liftも非常に魅力に溢れたフレームワークです。
（というか、個人的にはLiftの方が好きです。）

View First

Liftの最大の特徴として、MVCモデルではなく、View Firstというモデルを採用している事があげられます。
MVCモデルはもはや常識といってもいいくらい普及しているので、今更何故にMVCを否定するのか？と思う人も多いかと思います。

ただ、私は前々からMVCに対して以下の不満を持っていました。

View層にロジックが混ざっているのが気持ち悪いし、画面単体のテストがやりにくい。
Controllerの区切りが曖昧。1画面1コントローラやファットコントローラなど、適切に切り分けられているとは思えないコントローラが頻発する。

Liftならばこれらの問題を解決してくれます。

まず、View層は完全なHTMLですので、いったんHTMLで画面をデザインしたのちに、そのHTMLをそのままView層として利用する事が出来ます。
画面デザインに変更が入ったとしても、HTMLを編集すればいいだけなので非常に簡単です。

そして、動的な部分やロジックを含む部分のみをSnippetによって更新するので、一つのViewに対して複数のSnippetを対応させる事も、逆に複数のViewに対して共通のSnippetを対応させる事も、容易に行うことが出来ます。

Liftのメリット

Liftには以下のようなメリットがあります。

Scalaで実装されているので、処理速度が速い
フルスタックフレームワークの名に相応しく、必要な機能は一通り揃っている
Warパッケージにまとめて、Servletコンテナ上で動作させるので、既存のServletコンテナがそのまま利用できる
Scala専用のフレームワークなので、書き口が非常にScala然としている

特に二つ目のメリットは素晴らしく、 REST API構築、Ajax、Comet、JSONパーサ、セッション管理、ORマッパー（NoSQL対応）などのサポートは非常に充実しています。

Liftのデメリット

一方で、以下のようなデメリットがあります。

ソースコードが黒魔術化しており、並のScala使いでは解読不可能
文献が非常に少なく、日本語のドキュメントは壊滅的。英語ですら非常に限定的
Typesafe社がサポートするフレームワークはPlayであり、Liftのコミュニティはあまり栄えていない
リッチなViewを実装しようと思ったら、サーバサイド側のエンジニアもJavaScriptを書く事になり、Scalaのコードの中にJavaScriptの記述が混在する
国内では評価が低く、よくディスられている

二番目のデメリットはかなり問題で、私もかなり苦労しました。
ただ、英語の書籍で一冊だけバイブルと読めるものがあり、その書籍をベースに学習すれば、なんとか必要な知識は習得できます。
日本語の文献は本当に不足しているので、力添えになれるよう頑張って解説していくつもりです。

三番目のデメリットも中々辛いですが、この話には裏があり、もともとTypesafe社はLiftを公式フレームワークとして採用するつもりだったものの、Liftの開発者とTypesafe社で意見の食い違いが生じ、結局Playが採用される事になったらしいです。
とはいえ、人気をPlayにとられているのは間違いなく、Liftがこれからも継続して開発されていくのかには一抹の不安があります。しかし、Lift3.0の開発は着々と進んでおり、近々でサポートが無くなる事はなさそうです。

四番目のデメリットはある種View Firstモデルの限界に起因する話だと思います。ただ、Lift3.0では新機能で多少改善される？みたいです。

最後のはデメリットというか悲しくなるという話です。一応リンクを貼っておきます。
もっともだなぁという指摘もありますが。。。

Scala Liftの教訓 - Qiita

Play と Scala のこれまでとこれから - SSSSLIDE