弊社でScala+Liftを採用して5年が経ちました。主にガッチャ.jpでの採用では、多機能・高負荷・頻繁で大規模な仕様変更にもプログラマ1人でなんとか対応しています。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もそのうちの1つかもしれません。
ただ、そういった背景を差っ引いても、その頃のLiftはとてもじゃないけど、使いやすいとは言えませんでした。私が考える理由は主に2点。
ちょっとこれ厳しいよね、という雰囲気の中、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(必読)
closed.