Rails
Scala
Lift
sbt

Railsの逆を行く、デザイナと開発者が協力するためのScala Liftフレームワーク

More than 1 year has passed since last update.

最近のフレームワーク、っていうとどれもRailsと似たような感じで実装言語が違うだけでしょ?という感じですが、Liftはそんな中完全に逆を行ってます。

その思想は他の言語でも通用するはずなので、ぜひScalaなんぞ知らんという方も読んでいただければと思います。

Liftの特徴

公式な特徴はホームページに記載されていますが、個人的にプッシュしたいのは以下点です。これらは、Templatingに詳しく書かれています(日本語訳)。

1 デザイナフレンドリー
2 コントローラーがない
3 速い

デザイナフレンドリー

自分の手元にあるerbやらjspやらasp(chtml/vbhtml)やらのファイルを見て、これをサーバーサイド側の言語を知らない人間に手渡せるか?と考えたときYesと言える人はどれくらいいるでしょうか。

それらのファイルにはそこそこコードが入り組んでいて、特にRailsの場合顕著ですがHelperが紛れ込んでいる場合その筋の人でもよく分からんということも多いのではと思います。

これは正直開発者の生産性を重要視し続けた結果でもあり、異なるスキルを持つ人との協業を難しくしています。

そこでLiftですが、LiftのViewはhtmlです。変な拡張子ではないですし中身にScalaのコードがしゃしゃり出てくることもありません。DreamWeaverなどのデザインツールにも取り込むことができます。

ただ、その反面Scala側にHTMLが多少混じります。サーバーサイドにHTMLタグが入るということにやっぱり嫌な感じはありますが、それはRubyやらJavaのコードがViewに紛れ込んでいるのと同じことです。

これは完全にトレードオフで、Liftは他のフレームワークとは逆の選択をしたということです。実際、サーバーからレンダリングしないといけないタグは正直大したことない量なので、それほど気になりません。

コントローラーがない

猫も杓子もMVCでControllerですが、そもそもなんでControllerなんぞないといけないんでしょうか?邪魔だと思ったことはないですか?

大体1Viewに1Controllerが相場(?)ですが、多くのリッチな画面は画面上で複数の処理が走っているのが普通です。Qiitaの投稿画面でも、投稿件数、記事の自動保存といった非同期処理から、記事の投稿、画像のアップロードといった同期処理まで多数の処理が動いています。

これらを1Controllerにまとめるのは正直現実的ではありません。何らかの形で分割はするのでしょうが、それが難しいからこそFat Controllerという問題が起きてきたりJavaScript側のフレームワークがないと手に負えなくなってきたりするのだと思います。

LiftにはControllerなんかありません。投稿件数の表示なら表示、投稿なら投稿、と画面上のアクションに応じて完全にコードを分離できます(これをsnippetと呼びます)。

なんだか怖い気もしますが、でもこれは当然な気もします。
「画面上にある機能を分割し、それに応じてコードが書ける」。多くのフレームワークがMVCにこだわって失った機能の分割という利点を(Controllerを経由しないといけないという性質上、MVCで機能分割が行いにくいのはある意味必然)、Liftは逆を行くことで非常に理にかなったモジュール化を行うことができます。

速い

Scalaという静的型言語でしかも非同期に強いということだけでイケてますが、上記のようにControllerを廃してViewの機能分割(snippet化)を可能にしたことで、並列実行による部分View描画が可能になっています。

こちらにサンプルがありますが、これだけ簡単に書けるフレームワークは他にないと思います。

そういう意味では、snippetの思想からしてWebアプリケーションを関数型で記述しているような感がLiftにはあります。

主流に逆らいさまざまなメリットを得たLiftフレームワーク、ぜひ一度お試しあれ。

・・・といっても、情報がかなり少ないので(HelloWorld的なものしかない)、作り方についてまとめました。
View First で始める Scala Liftフレームワーク

そして、作っているうちにやっぱりそんなバラ色というわけにもいかないこともわかってきたので、こちらを追記しました。。。