弊社でScala+Liftを採用して5年が経ちました。主にガッチャ.jpでの採用では、多機能・高負荷・頻繁で大規模な仕様変更にもプログラマ１人でなんとか対応しています。Liftを選択して正解だったと今でも思います。

その間、ほとんど他のフレームワークに目がいかなかったほど、今のliftには満足していて「もうRails型の開発には戻れない！」という感覚になっています。
Play Framework for scala も良いのかもしれません（触ってない）が、めげずに「liftのココがすごい」というところをコツコツとエントリしていきたい。（もちろんこの5年、他の技術進化は全く追っていないので、そんなの当たり前的なこともエラそうに書くかもしれません。）

話は遡って、liftがWebフレームワークとして機能的にブレイクしたのは、3年前のLift2.2～2.3 あたり、CSS Selector Snippet / HTML5 Support を含めたDesigner Friendly Templatesの実装が入った後だと、個人的には思います。
これをきっかけに、機能やコード、ドキュメントなどが、よりやさしく、より短く簡単に、という方向に整備されていきました。

運悪く、日本のScala界隈でLiftが話題に上がっていたのは4年前のLift2.0あたりです。おそらくこのころに出てきた「Railsっぽくないフレームワーク」は、ほとんどが正当な評価を受けていないように思いますが、Liftもそのうちの１つかもしれません。

ただ、そういった背景を差っ引いても、その頃のLiftはとてもじゃないけど、使いやすいとは言えませんでした。私が考える理由は主に２点。

• テンプレートがvalidなXHTMLでなければならない。（一つでもタグの閉じ忘れがあると、盛大なスタックトレースがお出迎え）
• 動的箇所は <lift:someSnippet></lift:someSnippet> などというクソみたいなタグを埋め込まなければならなかった。Snippet側も文字列ではなくXMLを一生懸命生成しなければならなかった。ScalaにXMLリテラルがあるとはいえ、これは苦痛。

ちょっとこれ厳しいよね、という雰囲気の中、Lift2.2でガンガンよくわからない（※）機能追加されたあたりで、「もうLiftわからん、Liftはオワコン」的なムードになってしまいました。
※今思うに「素晴らしい」としかいいようのない機能ですが。

なので、Lift2.0/2.1あたりでLiftの評価をやめてしまった人は、再度Liftを使ってみて欲しいと思います。以下の違いを見て、何か反応する人には、共有できる情報になればいいと思います。

今のLiftは、ほとんど、というか全くHTMLに手を加える必要がありません。ここまで徹底したデザインとプログラムの分離ができるフレームワークは私は見たことがありません。

あと、ドキュメントはSimply　LiftやLift Cookbookを読みましょう。
Exploring Liftはオールドスタイルで混乱するのでもう読まなくていい情報、マニア向けと言えるでしょう。

1.Lift再入門
2.Snippetメソッドとして許される型
3.ログインFORM - S.param使ったら負け
4.サーバーサイドバリデーションとサーバサイド関数
5.行列型の編集FORM
6.Radio、Checkboxが鬼門？
7.Ajax Form
8.javascriptからsubmitできない

動作確認サンプルコード github
Simply Lift(必読)