我之前使用过play2和java。它感觉有点像样板文件，特别是如果你使用带有java的akka。但这不是框架的错误。
昨天我读了“Scala for the greatient”，我真的很喜欢这种语言。
现在我查看了两个框架Lift 2.5和Play 2.0.3。我认为电梯有更高的学习曲线，我不能只用电梯做一些事情。这不适合我。从我看到的，Lift有一个非常漂亮和干净的设计。
但对我来说，很难说主要的区别是什么。我认为这两个框架都很棒。
“视图优先”方法不允许您在模板中进行编码，而是必须使用代码段进行编码。我非常喜欢这个，因为它看起来更有条理。它还允许您使用普通的html编辑器。 （我的经验不多，这只是我的第一印象）
对于安全性，我认为这不是框架的工作。
无国籍/有状态：很难说主要区别在哪里。我只知道如果使用网络套接字，播放也会有状态。
按F5后，两个框架都可以编译。我非常喜欢这个功能。
两个框架都使用sbt
Lift附带授权，但我认为有一个play2 scala插件可以做同样的事情
Lift为mongoDB提供了一个ORM映射器。因为我想使用noSQL，这对我来说看起来更干净。（再次没有多少经验） 编辑在play2 https://github.com/leon/play-salat <中有scala mongodb的ORM映射器/ p>
异步 - Play 2使用Akka。不知道电梯使用的是什么，但它们也有类似的东西。
通过CSRF支持提升船舶。 Play2有一个CSRF模块，但这为你的代码增加了一个样板。
无状态身份验证似乎存在一些安全漏洞。两个框架都具有状态身份验证。 （play2 stateful / stateless，lift stateful）
答案 0 :(得分：76)
用Lift一两个星期后发布这个并不是真的 为任何人的利益服务。但是，我想花点时间纠正 一些错误和误解。
- 为了安全起见，我认为这不是框架的工作。
你错了。安全性是框架的工作。安全至关重要 默认情况下完成，而不是依赖每个开发人员来理解每一个 安全漏洞并确保每行代码都考虑到这一点。
我们所要做的只是看看GitHub发生了什么 了解即使是最好的编码人员也使用众所周知的技术 可以犯一个严重的错误。
Lift在顶部提供了一个可靠的安全层，因此默认情况下，没有XSS，CSRF等。 但开发人员可以深入挖掘他想要的HTTP请求和交易 用线上的字节。
- 无国籍/有状态：很难说主要区别在哪里。我只知道如果使用网络套接字，播放也会有状态。
提升非常清楚你需要在哪里和不在哪里。电梯可以支持 无状态，部分有状态和完全有状态的应用程序。在逐页和 按要求提供，Lift应用程序可以是有状态的或无状态的（例如， 在Foursquare中，场地页面是无国籍的 搜索引擎抓取，但对于已登录的浏览器是有状态的。）对于 更多关于州的设计决策，请参阅Lift, State, and Scaling。
- 两个框架都使用sbt
Lift使用Maven，sbt，Buildr甚至Ant。 Lift对构建环境不了解 关于部署环境（Java EE容器，Netty，等等）。这个很重要 因为它使Lift更容易与您的环境的其他部分集成。
- Lift附带授权，但我认为有一个play2 scala插件可以做同样的事情
Lift已经存在了5年多，并且有很多模块和东西。 Lift Web框架（与模块不同）与持久性，身份验证等无关，因此您可以使用Lift。
- Async - Play 2使用Akka。不知道电梯使用的是什么，但它们也有类似的东西。
Lift已经拥有超过5年的Async支持。它融入了框架。 Lift的Comet支持是the best of any web framework因为， 除此之外，它通过单个请求多路复用页面上的所有“推送”请求 到服务器，避免连接饥饿。 Lift是如何做异步的 不太重要，因为Lift的一个核心理念是我们删除了 来自开发人员的管道，因此开发人员可以专注于业务逻辑。
但对于那些关心的人来说，Lift拥有任何框架中最好，最轻的重量级演员 斯卡拉土地。我们是第一个脱离Scala Actor的图书馆并且工作的人 为允许Akka和ScalaZ Actors的不同Actor库开辟道路 蓬勃发展。
- 通过CSRF支持提升船舶。 Play2有一个CSRF模块，但这为你的代码增加了一个样板。
这是Lift对安全的承诺的一部分。这是important。
- 无状态身份验证似乎存在一些安全漏洞。两个框架都具有状态身份验证。 （play2 stateful / stateless，lift stateful）
提升应用可以是有状态的，也可以是无状态的。这是你的选择和提升 非常清楚如何做出决定。
另外，正如我在Lift，State和Scaling帖子中指出的那样，让开发人员弄明白 如何以安全，可扩展，高效的方式序列化状态 （因为几乎每个网络上的请求 识别特定用户的应用程序是有状态的，应该是可预测的， 框架的安全方式，为开发人员提供合理的覆盖。
游戏很像Rails：它很快就会让一个网站被撞倒在一起 基于MVC，很多开发人员都了解它。但是Play缺乏 Rails的深度和广度（社区，插件，专业知识，人才等）如果你 想要快速，简单的MVC，然后使用Rails和JRuby编写你的 Scala的后端（他们的工作非常好。）
升力是一种不同的野兽。有一个重要的学习曲线（停止思考 MVC并开始考虑用户体验，首先流向业务逻辑。） 但是，一旦你达到了学习曲线，Lift网站就会更加安全 可扩展，超级互动，并且随着时间的推移更容易维护。
答案 1 :(得分：20)
要了解Play可以做些什么（可能很酷），请查看TypeSafe Console
要快速使用Lift，请使用template project。
有关使用带有Play的Mongo的示例，请查看Factile。
总之，我认为升降机或游戏都不会出错。两者都是活跃的项目，拥有良好的社区和作者的良好支持。这真的取决于您的业务问题。如果工具支持对您很重要，那么您可能希望使用Play（它在IntelliJ Idea上得到很好的支持）。
请注意，作为TypeSafe技术堆栈的一部分，Play将构建最新版本的Scala，因此如果使用Scala 2.10功能对您很重要，那么您可能需要牢记这一点。 Lift目前正在使用Scala 2.9.2，这也很好。
对于我目前的项目，我使用lift-mapper进行ORM（它很棒且坚如磐石），使用Spray for REST（这简直太棒了）。这种方法完全避免了框架，但这取决于你想要做什么。框架通常是要走的路。