LiftとPlay2の比較
前にJavaでplay2を使用しました。特にakkaをJavaで使用している場合は、定型的な感じが少しありました。しかし、それはフレームワークのせいではありません。
昨日、「せっかちな人のためのスカラ」を読んで、言葉を本当に楽しんでいます。
次に、Lift 2.5とPlay 2.0.3の両方のフレームワークを見ました。リフトには学習曲線があり、リフトで何かをすることはできませんでした。これは私にとって短所ではありません。私が見たものから、Liftはとてもきれいできれいなデザインです。
しかし、私にとっては、主な違いが何であるかを伝えるのは難しいです。どちらのフレームワークも素晴らしいと思います。
Views Firstアプローチでは、テンプレートにコーディングすることはできません。代わりに、スニペットにコーディングする必要があります。これは私にとってより組織的に見えるので、これが大好きです。また、通常のhtmlエディターを使用できます。 （私はあまり経験がなく、これは私の最初の印象です）
セキュリティのために、私はそれがフレームワークの仕事だとは思いません。
ステートレス/ステートフル：主な違いがどこにあるのかわかりにくいです。 Webソケットを使用する場合、playにも状態があることを知っています。
F5を押した後、両方のフレームワークをコンパイルできます。この機能はとても気に入っています。
両方のフレームワークがsbtを使用しています
Liftには認証が付属していますが、同じことを行うplay2 scalaプラグインがあると思います
LiftにはmongoDBのORMマッパーがあります。私はnoSQLを使用したいので、これは私にはきれいに見えます。（あまり経験がない） Edit scala play2のmongodb https://github.com/leon/play-salat
非同期-Play 2はAkkaを使用します。リフトが何を使用するのかわかりませんが、同様の機能があります。
リフトにはCSRFサポートが付属しています。 Play2にはCSRF用のモジュールがありますが、これによりコードにボイラープレートが追加されます。
ステートレス認証にはセキュリティ上の脆弱性があるようです。どちらのフレームワークにもステートフル認証があります。 （play2ステートフル/ステートレス、ステートフルを持ち上げる）
- 各フレームワークの長所は何ですか？
Liftで1〜2週間過ごした後にこれを投稿しても、実際には誰の利益にもなりません。ただし、いくつかの間違いや誤解を修正するために時間を費やしたいと思います。
- セキュリティのために、私はそれがフレームワークの仕事だとは思いません。
あなたは完全に間違っています。セキュリティはフレームワークの仕事です。すべてのセキュリティの脆弱性を理解し、すべてのコード行がそれを考慮に入れるように各開発者に頼るのではなく、デフォルトでセキュリティを実行することが重要です。
私たちがしなければならないことは GitHub に何が起こったのかを見て、よく知られた技術を使用する最高のコーダーでさえ重大な間違いを犯す可能性があることを理解することです。
Liftは最上位に強固なセキュリティレイヤーを提供するため、デフォルトではXSS、CSRFなどはありませんが、開発者はHTTPリクエストを必要なだけ掘り下げて、ワイヤ上のバイトを処理できます。
- ステートレス/ステートフル：主な違いがどこにあるのかわかりにくいです。 Webソケットを使用する場合、playにも状態があることを知っています。
リフトは、状態が必要な場所とそうでない場所について非常に明確です。 Liftは、ステートレス、部分的にステートフル、完全にステートフルなアプリをサポートできます。ページごとおよびリクエストごとに、Liftアプリはステートフルまたはステートレスにすることができます（たとえば、 Foursquare の場合、ベニューページは検索エンジンクロールではステートレスですが、ログインしているブラウザ。）状態に関する設計上の決定の詳細については、 Lift、State、およびScaling を参照してください。
- 両方のフレームワークがsbtを使用しています
LiftはMaven、sbt、Buildr、さらにはAntを使用します。 Liftはビルド環境とデプロイ環境（Java EEコンテナ、Nettyなど）にとらわれません。 Liftは、他の環境との統合を容易にするため、これは重要です。
- Liftには認証が付属していますが、play2 scala同じことを行うプラグインがあると思います
Liftは5年以上前から存在しており、多くのモジュールとそれに対応するものがあります。 Lift Webフレームワーク（モジュールとは区別されます）は永続性、認証などに依存しないため、Liftでは何でも使用できます。
- 非同期-Play 2はAkkaを使用します。リフトが何を使用するのかわかりませんが、同様の機能があります。
Liftは5年以上にわたって非同期をサポートしています。フレームワークに組み込まれています。 LiftのCometサポートは、 あらゆるWebフレームワークの中で最高 です。これは、とりわけ、ページ上のすべての「プッシュ」リクエストを、サーバーへの単一リクエストを通じて多重化し、接続不足を回避するためです。 Liftの中心的な哲学の1つは、開発者が配管を取り除いてビジネスロジックに集中できるようにすることです。
しかし、気にする人のために、LiftはScala-landのどのフレームワークよりも優れた軽量のアクターを持っています。 Scala Actorのライブラリから脱却した最初の人であり、AkkaおよびScalaZ Actorsの繁栄を可能にしたさまざまなActorライブラリの道を切り開いた。
- リフトにはCSRFサポートが付属しています。 Play2にはCSRF用のモジュールがありますが、これによりコードにボイラープレートが追加されます。
これは、セキュリティに対するLiftの取り組みの一部です。 重要 です。
- ステートレス認証にはセキュリティ上の脆弱性があるようです。どちらのフレームワークにもステートフル認証があります。 （play2ステートフル/ステートレス、ステートフルを持ち上げる）
Liftアプリは、必要に応じてステートフルまたはステートレスにすることができます。それはあなたの選択であり、Liftは決定方法を非常に明確にします。
また、Lift、State、Scalingの投稿で指摘したように、開発者は、安全でスケーラブルでパフォーマンスの高い方法で状態をシリアル化する方法を理解できます（特定のユーザーを認識するWebアプリ上のすべてのリクエストはステートフルであるため）開発者にとって妥当なオーバーライドを使用して、フレームワークによって予測可能で安全な方法で行われます。
別れのメモ
PlayはRailsに非常によく似ています。サイトを簡単にまとめることができ、MVCに基づいているため、多くの開発者が理解しています。しかし、PlayにはRails（コミュニティ、プラグイン、専門知識、才能など）の深さと幅がありません。すばやく簡単なMVCが必要な場合は、Rails =およびJRubyで、バックエンドをScala（これらは非常にうまく機能します。）
リフトは別の獣です。重要な非学習曲線があります（MVCを考えるのをやめて、ビジネスロジックに流れるユーザーエクスペリエンスについて最初に考えることを始めます）。しかし、学習サイトから離れると、Liftサイトはより安全で、スケーラブルで、超対話的で、長期にわたって維持します。
Playで何ができるかを見るには（クールかもしれません） TypeSafe Console を見てください。
Liftをすばやく使用するには、 テンプレートプロジェクト を使用します。
PlayでMongoを使用するサンプルについては、 Factile をご覧ください。
要約すると、LiftまたはPlayのいずれかが間違っているとは思いません。どちらも活発なプロジェクトであり、優れたコミュニティと著者からの良い支援を受けています。それは本当にあなたのビジネス上の問題に依存します。ツールのサポートが重要な場合は、Playの使用を検討することをお勧めします（IntelliJ Ideaで十分にサポートされています）。
TypeSafeテクノロジースタックの一部であるPlayは、Scalaの最新バージョンまでビルドされることに注意してください。したがって、Scala 2.10機能を使用することが重要な場合は、 Liftは現在Scala 2.9.2を使用していますが、これも問題ありません。
私の現在のプロジェクトでは、REST（これは単に驚くべきことです）のスプレーで、ORMのリフトマッパーを使用します（これは素晴らしく、堅実です）。このアプローチはフレームワークを完全に回避しますが、フレームワークが非常に頻繁に使用されます。