scala 比较 Lift 和 Play2

Comparing Lift with Play2

提问by Maik Klein

I used play2 before with java. It felt a little bit like boilerplate especially if you used akka with java. But that is not the fault of the framework.

我之前用 java 使用过 play2。感觉有点像样板文件，尤其是如果您将 akka 与 java 一起使用。但这不是框架的错。

Yesterday I read "Scala for the impatient" and I really enjoy the language.

昨天我读了“不耐烦的 Scala”，我真的很喜欢这门语言。

Now I looked at both frameworks Lift 2.5 and Play 2.0.3. I think lift has a higher learning curve and I could not just do something with lift. This is not a con for me. From what I saw, Lift has a very nice and clean design.

现在我查看了 Lift 2.5 和 Play 2.0.3 这两个框架。我认为 Lift 有更高的学习曲线，我不能只用 Lift 做一些事情。这对我来说不是骗局。据我所知，Lift 的设计非常漂亮和干净。

But for me it is hard to tell what the main differences are. I think both frameworks are great.

但对我来说，很难说出主要的区别是什么。我认为这两个框架都很棒。

• The Views First approach doesn't allow you to code in your templates, instead you have to code in snippets. I like this a lot because it looks more organized to me. It also lets you use a normal html editor. (I have not much experience, this is just my first impression)

• For the security I don't think that is the job of the framework.

• Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.

• Both frameworks are able to compile after you press F5. I like this feature a lot.

• Both frameworks are using sbt

• Lift comes with authorization but I think there is a play2 scala plugin that does the same thing

• Lift has a ORM mapper for mongoDB. Because I want to use noSQL, this looks cleaner to me.(Again not much experience)EditThere is a ORM mapper for scala mongodb in play2 https://github.com/leon/play-salat

• Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.

• Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.

• Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)

• Views First 方法不允许您在模板中编码，而必须在片段中编码。我很喜欢这个，因为它看起来更有条理。它还允许您使用普通的 html 编辑器。 （我没有太多经验，这只是我的第一印象）

• 对于安全性，我认为这不是框架的工作。

• 无状态/有状态：很难说主要区别在哪里。我只知道如果你使用网络套接字，播放也有一个状态。

• 按 F5 后，这两个框架都可以编译。我非常喜欢这个功能。

• 两个框架都在使用 sbt

• Lift 带有授权，但我认为有一个 play2 scala 插件可以做同样的事情

• Lift 有一个用于 mongoDB 的 ORM 映射器。因为我想使用 noSQL，这对我来说看起来更干净。（再次没有太多经验）编辑在 play2 https://github.com/leon/play-salat 中有一个用于 scala mongodb 的 ORM 映射器

• Async - Play 2 使用 Akka。不知道电梯使用什么，但它们也有类似的东西。

• 提升船与 CSRF 支持。Play2 有一个用于 CSRF 的模块，但这会为您的代码添加一个样板。

• 无状态身份验证似乎存在一些安全漏洞。两个框架都有状态认证。（play2 有状态/无状态，提升有状态）

---

---

---

---

• What are the strengths of each framework?

• 每个框架的优势是什么？

回答by David Pollak

Posting this after spending a week or two with Lift doesn't really serve anybody's interests. However, I want to spend some time correcting some mistakes and mis-perceptions.

在使用 Lift 一两个星期后发布此信息并不能真正满足任何人的利益。但是，我想花一些时间纠正一些错误和误解。

• For the security I don't think that is the job of the framework.

• 对于安全性，我认为这不是框架的工作。

You're dead wrong. Security is the job of the framework. It's critical that security is done by default rather than relying on each developer to understand every security vulnerability and make sure every line of code takes that into account.

你大错特错。安全是框架的工作。安全是默认完成的，而不是依赖每个开发人员了解每个安全漏洞并确保每一行代码都考虑到这一点，这一点至关重要。

All we have to do is look at what happened to GitHubto understand that even the best coders using well known technology can make a critical mistake.

我们所要做的就是查看GitHub 上发生的事情， 以了解即使是使用众所周知技术的最佳编码员也可能犯下严重错误。

Lift gives a solid security layer on top, so by default, there's no XSS, CSRF, etc. but the developer can dig down as deep as he wants to the HTTP request and deal with the bytes on the wire.

Lift 在顶部提供了一个可靠的安全层，因此默认情况下，没有 XSS、CSRF 等，但开发人员可以深入挖掘 HTTP 请求并处理线路上的字节。

• Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.

• 无状态/有状态：很难说主要区别在哪里。我只知道如果你使用网络套接字，播放也有一个状态。

Lift is very clear about where you need state and where you don't. Lift can support stateless, partially stateful, and completely stateful apps. On a page-by-page and request-by-request basis, a Lift app can be stateful or stateless (for example, in Foursquare, the venue pages are stateless for search engine crawls, but stateful for browsers that are logged in.) For more on the design decisions around state, please see Lift, State, and Scaling.

Lift 非常清楚哪些地方需要状态，哪些地方不需要。Lift 可以支持无状态、部分有状态和完全有状态的应用程序。在逐页和逐个请求的基础上，Lift 应用程序可以是有状态的或无状态的（例如，在Foursquare 中，场地页面对于搜索引擎抓取是无状态的，但对于已登录的浏览器是有状态的。）有关围绕状态的设计决策的更多信息，请参阅Lift、State 和 Scaling。

• Both frameworks are using sbt

• 两个框架都在使用 sbt

Lift uses Maven, sbt, Buildr, and even Ant. Lift is agnostic about the build environment and about the deploy environment (Java EE container, Netty, whatever). This is important because it make Lift easier to integrate with the rest of your environment.

Lift 使用 Maven、sbt、Buildr，甚至 Ant。Lift 与构建环境和部署环境（Java EE 容器、Netty 等）无关。这很重要，因为它使 Lift 更容易与您的环境的其余部分集成。

• Lift comes with authorization but I think there is a play2 scala plugin that does the same thing

• Lift 带有授权，但我认为有一个 play2 scala 插件可以做同样的事情

Lift has been around for 5+ years and has a lot of modules and stuff for it. The Lift web framework (as distinguished from the modules) is agnostic about persistence, authentication, etc., so you can use anything with Lift.

Lift 已经存在 5 年以上，并且有很多模块和东西。Lift Web 框架（与模块不同）与持久性、身份验证等无关，因此您可以在 Lift 中使用任何东西。

• Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.

• Async - Play 2 使用 Akka。不知道电梯使用什么，但它们也有类似的东西。

Lift has had Async support for more than 5 years. It's baked into the framework. Lift's Comet support is the best of any web frameworkbecause, among other things, it multiplexes all the "push" requests on a page through a single request to the server which avoids connection starvation. How Lift does async is a whole lot less important because one of the core philosophies with Lift is that we remove the plumbing from the developer so the developer can focus on business logic.

Lift 已获得异步支持超过 5 年。它已融入框架。Lift 的 Comet 支持是所有 Web 框架中最好的，因为除其他外，它通过对服务器的单个请求将页面上的所有“推送”请求多路复用，从而避免了连接匮乏。Lift 如何进行异步并不那么重要，因为 Lift 的核心理念之一是我们从开发人员那里移除管道，以便开发人员可以专注于业务逻辑。

But for those who care, Lift has the best and lightest weight actors of any framework in Scala-land. We were the first to break away from the Scala Actor's library and worked to blaze the trail for different Actor libraries that allowed Akka and ScalaZ Actors to flourish.

但对于那些关心的人来说，Lift 拥有 Scala 领域所有框架中最好和最轻的演员。我们是第一个脱离 Scala Actor 库的人，并致力于为不同的 Actor 库开辟道路，让 Akka 和 ScalaZ Actors 蓬勃发展。

• Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.

• 提升船与 CSRF 支持。Play2 有一个用于 CSRF 的模块，但这会为您的代码添加一个样板。

This is part of Lift's commitment to security. It's important.

这是 Lift 对安全性承诺的一部分。这很重要。

• Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)

• 无状态身份验证似乎存在一些安全漏洞。两个框架都有状态认证。（play2 有状态/无状态，提升有状态）

Lift apps can be as stateful or as stateless as you want. It's your choice and Lift makes very clear how to make the decision.

Lift 应用程序可以是有状态的，也可以是无状态的。这是您的选择，Lift 非常清楚如何做出决定。

Also, as I pointed out in the Lift, State, and Scaling post, making the developer figure out how to serialize state in a secure, scalable, performant way (because virtually every request on a web app that recognizes specific users is stateful) should be done in a predictable, secure way by the framework with reasonable overrides for the developers.

此外，正如我在 Lift、State 和 Scaling 帖子中指出的那样，让开发人员弄清楚如何以安全、可扩展、高性能的方式序列化状态（因为几乎每个 Web 应用程序上识别特定用户的请求都是有状态的）应该由框架以可预测的、安全的方式完成，并为开发人员提供合理的覆盖。

Parting note

离别笔记

Play is a lot like Rails: it's quick to get a site knocked together and it's based on MVC, so a lot of developers understand it. But Play lacks the depth and breadth of Rails (community, plugins, expertise, talent, etc.) If you want quick, easy MVC, then go with Rails and JRuby and write your back end in Scala (they work together extraordinarily well.)

Play 很像 Rails：将站点组合在一起的速度很快，而且它基于 MVC，因此很多开发人员都了解它。但是 Play 缺乏 Rails 的深度和广度（社区、插件、专业知识、人才等）。如果您想要快速、简单的 MVC，那么使用 Rails 和 JRuby 并在 Scala 中编写您的后端（它们协同工作非常好。）

Lift is a different beast. There's a significant unlearning curve (stop thinking MVC and start thinking about user experience first that flows to business logic.) But once you're up the unlearning curve, Lift sites are more secure, highly scalable, super-interactive, and much easier to maintain over time.

电梯是一个不同的野兽。有一个重要的忘却曲线（停止思考 MVC 并开始首先考虑流向业务逻辑的用户体验。）但是一旦你达到了忘却曲线，Lift 站点就会更安全、高度可扩展、超级交互，并且更容易随着时间的推移保持。

回答by Hyman

To see what can be done with Play (it can be cool), have a look at the TypeSafe Console

要了解 Play 可以做什么（它可以很酷），请查看TypeSafe 控制台

To get going quick with Lift, use a template project.

要快速使用 Lift，请使用模板项目。

For a sample of using Mongo with Play, look at Factile.

有关在 Play 中使用 Mongo 的示例，请查看Factile。

In summary, I don't think you will go wrong with either Lift or Play. Both are active projects, with good communities and good backing from the authors. It really depends on your business problem. If tool support are important to you, then you may want to look at using Play (it's well supported on IntelliJ Idea).

总而言之，我认为无论是 Lift 还是 Play，您都不会出错。两者都是活跃的项目，拥有良好的社区和作者的良好支持。这实际上取决于您的业务问题。如果工具支持对您很重要，那么您可能需要考虑使用 Play（它在 IntelliJ Idea 上得到了很好的支持）。

Take note that Play, being part of the TypeSafe technology stack, will have builds up to the latest versions of Scala, so if using Scala 2.10 features are important to you, then you may want to keep that in mind. Lift is currently using Scala 2.9.2, which is fine also.

请注意，Play 作为 TypeSafe 技术堆栈的一部分，将构建到最新版本的 Scala，因此如果使用 Scala 2.10 功能对您很重要，那么您可能需要记住这一点。Lift 目前使用的是 Scala 2.9.2，这也很好。

For my current project I use lift-mapper for ORM (It's great and rock solid), with Spray for REST (which is simply amazing). This approach avoids frameworks altogether, but it depends on what you want to do. Frameworks are quite often the way to go.

对于我当前的项目，我使用用于 ORM 的提升映射器（它很棒而且坚如磐石），使用用于 REST 的喷雾（这简直太棒了）。这种方法完全避免了框架，但这取决于您想要做什么。框架通常是要走的路。