为什么我要在 Java/Spring 上使用 Scala/Lift？

Why would I use Scala/Lift over Java/Spring?

提问by Chris J

I know this question is a bit open but I have been looking at Scala/Lift as an alternative to Java/Spring and I wonder what are the real advantages that Scala/Lift has over it. From my perspective and experience, Java Annotations and Spring really minimizes the amount of coding that you have to do for an application. Does Scala/Lift improve upon that?

我知道这个问题有点开放，但我一直将 Scala/Lift 视为 Java/Spring 的替代品，我想知道 Scala/Lift 相对于它的真正优势是什么。从我的角度和经验来看，Java Annotations 和 Spring 确实最大限度地减少了您必须为应用程序执行的编码量。Scala/Lift 会改进吗？

采纳答案by Dan LaRocque

Let's assume we're equally comfortable in Scala and Java, and ignore the (huge) language differences except as they pertain to Spring or Lift.

假设我们对 Scala 和 Java 同样熟悉，并忽略（巨大的）语言差异，除非它们与 Spring 或 Lift 相关。

Spring and Lift are almost diametrically opposed in terms of maturity and goals.

Spring 和 Lift 在成熟度和目标方面几乎截然相反。

• Spring is about five years older than Lift
• Lift is monolithic and targets only the web; Spring is modular and targets both web and "regular" apps
• Spring supports a plethora of Java EE features; Lift ignores that stuff

• Spring 大约比 Lift 大五岁
• Lift 是整体式的，仅针对网络；Spring 是模块化的，针对 Web 和“常规”应用程序
• Spring 支持大量的 Java EE 特性；Lift 忽略了那些东西

In a sentence, Spring is heavyweight and Lift is lightweight. With sufficient determination and resources you can turn that on its head, but you would need a lotof both.

一句话，Spring是重量级的，Lift是轻量级的。有了足够的决心和资源，您就可以扭转局面，但这两者都需要很多。

Here are concrete differences that stuck in my mind after working with both frameworks. This isn't an exhaustive list, which I can't compile anyhow. Just what seemed most interesting to me...

在使用这两个框架后，以下是我脑海中浮现的具体差异。这不是一个详尽的列表，无论如何我都无法编译。对我来说最有趣的是什么......

1. View philosophy

   Lift encourages placing some view material in snippet/action methods. Snippet code especially will be sprinkled with programmatically generated form elements, <div>s, <p>s, etc.

   This is powerful and useful, especially since Scala has a builtin language-level XML mode. One can write XML inline within Scala methods, including variable bindings in braces. This can be delightful for very simple XML services or mockups of services -- you can bang out a suite of HTTP response actions all in one splendidly terse file, without templates or much attendant configuration. The downside is complexity. Depending on how far you go, there's either a fuzzy separation of concerns between view and logic, or no separation.

   In contrast, regular use of Spring for webapps enforces a strong separation between the view and everything else. I think Spring supports several templating engines, but I've only used JSP in anything serious. Doing a Lift-inspired "fuzzy MVC" design with JSP would be madness. This is a good thing on larger projects, where the time to just read and understand can be overwhelming.

2. Object-Relational Mapper Choices

   Lift's builtin ORM is "Mapper". There's an upcoming alternative called "Record", but I think it's still considered pre-alpha. The LiftWeb Book has sections on using both Mapper and JPA.

   Lift's CRUDifyfeature, cool as it is, only works with Mapper (and not JPA).

   Of course, Spring supports a panoply of standard and/or mature database technologies. The operative word there is "supports". Theoretically, you can use any Java ORM with Lift, since you can call arbitrary Java code from Scala. But Lift only really supports Mapper and (to a much lesser extent) JPA. Also, working with nontrivial Java code in Scala is currently not as seamless as one might like; using a Java ORM, you will probably find yourself either using both Java and Scala collections everywhere or converting all collections in and out of the Java components.

3. Configuration

   Lift apps are configured pretty much entirely through a method an application-wide "Boot" class. In other words, the config is done through Scala code. This is perfect for projects with brief configurations, and when the person doing the configuring is comfortable editing Scala.

   Spring is pretty flexible in terms of configuration. Lots of conf options can be driven either through XML configuration or annotations.

4. Documentation

   Lift's documentation is young. Spring's docs are pretty mature. There's no contest.

   Since Spring's docs are already nicely organized and easy to find, I'll review the docs I found for Lift. There are basically 4 sources of Lift documentation: the LiftWeb Book, the API Docs, LiftWeb's Google group, and "Getting Started". There's also a nice suite of code examples, but I wouldn't call them "documentation" per se.

   The API docs are incomplete. The LiftWeb Book has been published on trees, but it's also freely available online. It is really useful, although its decidedly didactic style irritated me at times. It's a little long on tutorial and short on contract. Spring has a proper manual, which Lift lacks.

   But Lift does have a nice set of examples. If you're comfortable reading the Lift code and example code (and you know Scala well already), you can work things out in fairly short order.

1. 查看理念

   Lift 鼓励在片段/操作方法中放置一些视图材料。片段代码尤其会散布以编程方式生成的表单元素、<div>s、<p>s 等。

   这是强大而有用的，尤其是因为 Scala 具有内置的语言级 XML 模式。可以在 Scala 方法中编写内联 XML，包括括号中的变量绑定。这对于非常简单的 XML 服务或服务模型来说是令人愉快的——您可以在一个非常简洁的文件中生成一套 HTTP 响应操作，而无需模板或大量伴随的配置。缺点是复杂。根据您走多远，视图和逻辑之间的关注点要么模糊分离，要么没有分离。

   相比之下，Web 应用程序经常使用 Spring 会强制视图和其他所有内容之间进行强分离。我认为 Spring 支持多种模板引擎，但我只在任何严肃的事情中使用过 JSP。使用 JSP 进行受 Lift 启发的“模糊 MVC”设计将是疯狂的。这对于大型项目来说是一件好事，因为阅读和理解的时间可能会让人不知所措。

2. 对象关系映射器选择

   Lift 的内置 ORM 是“Mapper”。有一个名为“Record”的即将到来的替代方案，但我认为它仍然被认为是 pre-alpha。LiftWeb Book 有关于使用 Mapper 和 JPA 的部分。

   Lift 的CRUDify功能虽然很酷，但仅适用于 Mapper（而非 JPA）。

   当然，Spring 支持一整套标准和/或成熟的数据库技术。有效的词是“支持”。理论上，您可以将任何 Java ORM 与 Lift 结合使用，因为您可以从 Scala 调用任意 Java 代码。但是 Lift 只真正支持 Mapper 和（在较小程度上）JPA。此外，目前在 Scala 中使用非平凡的 Java 代码并不像人们想象的那样无缝；使用 Java ORM，您可能会发现自己要么在任何地方同时使用 Java 和 Scala 集合，要么在 Java 组件内外转换所有集合。

3. 配置

   Lift 应用程序几乎完全通过应用程序范围的“Boot”类方法进行配置。换句话说，配置是通过 Scala 代码完成的。这非常适合具有简短配置的项目，并且当进行配置的人可以轻松地编辑 Scala 时。

   Spring 在配置方面非常灵活。许多 conf 选项可以通过 XML 配置或注释来驱动。

4. 文档

   Lift 的文档还很年轻。Spring 的文档非常成熟。没有比赛。

   由于 Spring 的文档已经井井有条且易于查找，因此我将查看我为 Lift 找到的文档。Lift 文档基本上有 4 个来源：LiftWeb Book、API Docs、LiftWeb 的Google 组和“入门”。还有一套很好的代码示例，但我不会将它们称为“文档”本身。

   API 文档不完整。LiftWeb Book 已出版在树上，但也可在线免费获取。它真的很有用，尽管它明显的说教风格有时让我很恼火。教程有点长，合同有点短。Spring 有一本合适的手册，而 Lift 却没有。

   但 Lift 确实有一组很好的例子。如果您喜欢阅读 Lift 代码和示例代码（并且您已经很了解 Scala），那么您可以在相当短的时间内解决问题。

Both frameworks are compelling. There's a broad range of apps where you can choose either and do well.

这两个框架都令人信服。有很多应用程序可供您选择并做得很好。

回答by Roman

Just for fun. And for the sake of learning new programming approaches.

只是为了好玩。为了学习新的编程方法。

回答by gpampara

Expanding your knowledge is always a worthwhile endeavor :) I just started learning Scala, it's affecting how I write normal Java and I can say it's been very beneficial so far.

扩展您的知识总是值得的：) 我刚开始学习 Scala，它影响了我编写普通 Java 的方式，我可以说到目前为止它非常有益。

回答by pr1001

I didn'tcome to Lift and Scala from a Java background, so this isn't from personal experience, but I know that many Lift developers find Scala to be a much more concise and efficient language than Java.

我不是从 Java 背景来到 Lift 和 Scala 的，所以这不是来自个人经验，但我知道许多 Lift 开发人员发现 Scala 是一种比 Java 更简洁和高效的语言。

回答by Berlin Brown

I hate to completely throw your world for a loop. But you can you use Scala, Java, Lift, Spring in one application and have it not be a problem.

我讨厌完全让你的世界陷入困境。但是您可以在一个应用程序中使用 Scala、Java、Lift 和 Spring，并且它不是问题。

回答by IPC

I would recommend you to check play framework, it has some very interesting ideas and supports development in Java and Scala

我建议您查看 play 框架，它有一些非常有趣的想法，并支持 Java 和 Scala 开发

回答by David Pollak

I've gotta say that I strongly disagree with Dan LaRocque's answer.

我不得不说我非常不同意 Dan LaRocque 的回答。

Lift is not monolithic. It is composed on discrete elements. It does not ignore J/EE elements, it support the likes of JNDI, JTA, JPA, etc. The fact that you're not forced to uses these elements of J/EE is a strong indication of Lift's modular design.

Lift 不是整体式的。它由离散元素组成。它不会忽略 J/EE 元素，它支持 JNDI、JTA、JPA 等。事实上，您不会被迫使用 J/EE 的这些元素，这有力地表明了 Lift 的模块化设计。

• Lift's view philosophy is "let the developer decide." Lift offers a templating mechanism that does not allow any logic code in the view, a view mechanism based on executing Scala code and Scala's XML literals, and a view mechanism based on Scalate. If you choose the XML templating mechanism, then you choose how much, if any, mark-up belongs in your business logic. Lift's view separation is stronger than anything Spring has to offer because you cannot express any business logic in Lift's XML templates.
• Lift's Object ↔ Persistence philosophy is "let the developer decide." Lift has Mapper which is an ActiveRecord style object relational mapper. It gets the job done for small projects. Lift support JPA. Lift has a Record abstraction that supports shuttling objects into and out of relational databases, into and out of NoSQL stores (Lift includes native support for CouchDB and MongoDB, but the adapter layers are a few hundred lines of code, so if you want Cassandra or something else, it's not a lot of work to get it.) Basically, Lift the Web Framework has no dependence on how objects are materialized into a session. Further, the session and request cycles are open such that inserting transaction hooks into the request/response cycle is simple.
• Lift's philosophy is "the server team needs to know one language, not multiple languages." This means that configuration is done via Scala. This means that we didn't have to implement 40% of Java's language constructs in XML syntax to create flexible configuration options. It means that the compiler syntax and type-checks the configuration data so you don't get any weird XML parsing or incorrect data at runtime. In means that you don't have to have IDEs that understand the particulars of the annotations that you're using based on the library that you're using.
• Yep, Lift's documentation is not its strong point.

• Lift 的观点哲学是“让开发者决定”。Lift 提供了一个模板机制，不允许视图中有任何逻辑代码，一个基于执行 Scala 代码和 Scala 的 XML 文字的视图机制，以及一个基于Scalate的视图机制。如果您选择 XML 模板机制，那么您将选择多少标记（如果有）属于您的业务逻辑。Lift 的视图分离比 Spring 提供的任何东西都要强大，因为您无法在 Lift 的 XML 模板中表达任何业务逻辑。
• Lift's Object ↔ Persistence 的理念是“让开发者决定”。Lift 有 Mapper，它是一个 ActiveRecord 风格的对象关系映射器。它可以完成小型项目的工作。提升支持 JPA。Lift 有一个 Record 抽象，支持对象进出关系数据库，进出 NoSQL 存储（Lift 包括对 CouchDB 和 MongoDB 的本机支持，但适配器层只有几百行代码，所以如果你想要 Cassandra 或别的东西，要得到它并不是很多工作。）基本上，Lift the Web Framework 不依赖于对象如何具体化到会话中。此外，会话和请求周期是开放的，因此将事务挂钩插入请求/响应周期很简单。
• Lift 的理念是“服务器团队需要知道一种语言，而不是多种语言。” 这意味着配置是通过 Scala 完成的。这意味着我们不必在 XML 语法中实现 40% 的 Java 语言构造来创建灵活的配置选项。这意味着编译器语法和类型检查配置数据，因此您不会在运行时得到任何奇怪的 XML 解析或不正确的数据。In 意味着您不必拥有能够根据您正在使用的库了解您正在使用的注释的详细信息的 IDE。
• 是的，Lift 的文档并不是它的强项。

With the above being said, let me talk some about Lift's design philosophy.

说了这么多，我来谈谈Lift的设计理念。

I wrote Web Framework Manifestobefore I started writing Lift. To a great degree, and to a greater degree than is true for any other web framework that I know of, Lift meets these goals.

在开始编写 Lift 之前，我编写了Web Framework Manifesto。在很大程度上，并且比我所知道的任何其他 Web 框架都更真实，Lift 满足了这些目标。

Lift at its core seeks to abstract away the HTTP request/response cycle rather than placing object wrappers around the HTTP Request. At the practical level, this means that most any action that a user can take (submitting form elements, doing Ajax, etc.) is represented by a GUID in the browser and a function on the server. When the GUID is presented as part of the an HTTP request, the function is applied (called) with the supplied parameters. Because the GUIDs are hard to predict and session-specific, replay attacks and many parameter tampering attacks are far more difficult with Lift than most other web frameworks, including Spring. It also means that developers are more productive because they are focusing on user actions and the business logic associated with user actions rather than the plumbing of packing and unpacking an HTTP request. For example, code for accepting or rejecting a FourSquare friend request:

Lift 的核心是试图抽象出 HTTP 请求/响应周期，而不是在 HTTP 请求周围放置对象包装器。在实际层面，这意味着用户可以采取的大多数操作（提交表单元素、执行 Ajax 等）都由浏览器中的 GUID 和服务器上的功能表示。当 GUID 作为 HTTP 请求的一部分呈现时，函数将使用提供的参数应用（调用）。由于 GUID 难以预测且特定于会话，Lift 的重放攻击和许多参数篡改攻击比包括 Spring 在内的大多数其他 Web 框架要困难得多。这也意味着开发人员的工作效率更高，因为他们专注于用户操作和与用户操作相关的业务逻辑，而不是打包和解包 HTTP 请求的管道。

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

It's that simple. Because the friendRequest is in the scope when the function is created, the function closes over the scope... there's no need to expose the primary key of the friend request or do anything else... just define the text of the button (it can be localized or it can be pulled from an XHTML template or it can be pulled from a localized template) and the function to execute when the button is pushed. Lift takes care of assigning the GUID, setting up the Ajax call (via jQuery or YUI, and yes, you can add your own favorite JavaScript library), doing automatic retries with back-offs, avoiding connection starvation by queuing Ajax requests, etc.

就这么简单。因为在函数创建时，friendRequest 在作用域内，所以函数在作用域上关闭......没有必要暴露好友请求的主键或做任何其他事情......只需定义按钮的文本（它可以本地化，也可以从 XHTML 模板中提取，也可以从本地化模板中提取）以及按下按钮时要执行的函数。Lift 负责分配 GUID、设置 Ajax 调用（通过 jQuery 或 YUI，是的，您可以添加自己喜欢的 JavaScript 库）、使用回退进行自动重试、通过排队 Ajax 请求避免连接饥饿等。

So, one big difference between Lift and Spring is that Lift's philosophy of GUID associated with function has the dual benefit of much better security and much better developer productivity. The GUID -> Function association has proven very durable... the same construct works for normal forms, ajax, comet, multi-page wizards, etc.

因此，Lift 和 Spring 之间的一大区别在于，Lift 与函数关联的 GUID 哲学具有双重好处，即更好的安全性和更好的开发人员生产力。GUID -> 函数关联已被证明非常耐用……相同的构造适用于普通表单、ajax、comet、多页向导等。

The next core piece of Lift is keeping the high level abstractions around for as long as possible. On the page generation side, that means building the page as XHTML elements and keeping the page as XHTML until just before streaming the response. The benefits are resistance to cross site scripting errors, the ability to move CSS tags to the head and scripts to the bottom of the page after the page has been composed, and the ability to rewrite the page based on the target browser. On the input side, URLs can be re-written to extract parameters (both query and path parameters) in a type-safe manner, high level, security checked data is available for processing very early in the request cycle. For example, here's how to define servicing of a REST request:

Lift 的下一个核心部分是尽可能长时间地保留高级抽象。在页面生成方面，这意味着将页面构建为 XHTML 元素并将页面保持为 XHTML，直到流响应之前。好处是可以抵抗跨站点脚本错误，能够在页面组成后将 CSS 标签移动到页面的头部并将脚本移动到页面的底部，以及基于目标浏览器重写页面的能力。在输入端，可以重写 URL 以以类型安全的方式提取参数（查询和路径参数），高级别的安全检查数据可用于在请求周期的早期进行处理。例如，以下是定义 REST 请求服务的方法：

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

Using Scala's built-in pattern matching, we match an incoming request, extract the third part of the path and get the User that corresponds to that value, and even apply access control checks (does the current session or request have permissions to access the given User record). So, by the time the User instance hits the application logic, it's vetted.

使用 Scala 的内置模式匹配，我们匹配传入的请求，提取路径的第三部分并获取与该值对应的用户，甚至应用访问控制检查（当前会话或请求是否有权访问给定的用户记录）。因此，当 User 实例访问应用程序逻辑时，它已被。

With these two core pieces, Lift has a tremendous advantage in terms of security. To give you an idea of the magnitude of Lift's security that doesn't get in the way of features, Rasmus Lerdorgwho did security for Yahoo! had this to say about FourSquare (one of the Lift poster-child sites):

有了这两个核心部分，Lift 在安全性方面具有巨大的优势。为了让您了解不会妨碍功能的 Lift 安全性的重要性，为 Yahoo! 提供安全性的Rasmus Lerdorg！关于 FourSquare（Lift 海报子网站之一）有这样的说法：

Four stars to @foursquare - 1st site in a while I have taken a good look at that didn't have a single security issue (that I could find) -- http://twitter.com/rasmus/status/5929904263

四颗星给@foursquare - 一段时间以来的第一个站点，我仔细查看了它没有任何安全问题（我可以找到） - http://twitter.com/rasmus/status/5929904263

At the time, FourSquare had one engineer working on the code (not that @harryh isn't a super-genius) and his main focus was re-writing the PHP version of FourSquare while coping with weekly traffic doubling.

当时，FourSquare 有一名工程师负责代码（并不是说@harryh 不是超级天才），他的主要重点是在应对每周流量翻番的同时重写 FourSquare 的 PHP 版本。

The last part of Lift's security focus is SiteMap. It's a unified access control, site navigation, and menu system. The developer defines the access control rules for each page using Scala code (e.g. If(User.loggedIn _)or If(User.superUser _)) and those access control rules are applied before any page rendering starts. This is much like Spring Security, except that it's baked in from the beginning of the project and the access control rules are unified with the rest of the application so you don't have to have process for updating the security rules in XML when the URLs change or the methods that calculate the access control change.

Lift 安全重点的最后一部分是 SiteMap。它是一个统一的访问控制、站点导航和菜单系统。开发人员使用 Scala 代码（例如If(User.loggedIn _)或If(User.superUser _)）为每个页面定义访问控制规则，并且在任何页面呈现开始之前应用这些访问控制规则。这很像 Spring Security，不同之处在于它从项目开始就被引入，并且访问控制规则与应用程序的其余部分统一，因此当 URLs更改或计算访问控制更改的方法。

To summarize so far, Lift's design philosophy gives you the benefits of baked in access control, resistance to the OWASP top 10 security vulnerabilities, much better Ajax support and much higher developer productivity than does Spring.

到目前为止，总而言之，Lift 的设计理念为您提供了访问控制的好处、对 OWASP 前 10 名安全漏洞的抵抗力、比 Spring 更好的 Ajax 支持和更高的开发人员生产力。

But Lift also gives you the best Comet support of any web framework around. That's why Novell chose Lift to power their Pulse productand here's what Novell has to say about Lift:

但是 Lift 还为您提供了任何 Web 框架中最好的 Comet 支持。这就是 Novell 选择 Lift 为其Pulse 产品提供动力的原因，以下是 Novell 对 Lift 的评价：

Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level features like the built-in Comet support allow you to focus on innovating instead of the plumbing. Building a rich, real-time web application like Novell Pulse requires a framework with the power of Lift under the covers.

Lift 是一种 Web 框架，可让您作为开发人员专注于大局。强大、富有表现力的输入和更高级的功能（如内置 Comet 支持）让您可以专注于创新而不是管道。构建像 Novell Pulse 这样丰富的实时 Web 应用程序需要一个具有 Lift 强大功能的框架。

So, Lift is not just another me-too MVC framework. It's a framework that's got some core design principles behind it that have matured very well. It's a framework that gives the dual advantages of security and developer productivity. Lift is a framework that's built in layers and gives the developer the right choices based on their needs... choices for view generation, choices for persistence, etc.

因此，Lift 不仅仅是另一个类似的 MVC 框架。这是一个框架，其背后有一些已经非常成熟的核心设计原则。它是一个具有安全性和开发人员生产力双重优势的框架。Lift 是一个内置于层中的框架，并根据开发人员的需求为开发人员提供正确的选择……视图生成的选择、持久性的选择等。

Scala and Lift give developers a much better experience than the melange of XML, annotations, and other idioms that make up Spring.

与构成 Spring 的 XML、注释和其他习语的混合体相比，Scala 和 Lift 为开发人员提供了更好的体验。

回答by mguymon

I strongly looked into using Lift for a recent web project, not being a big fan of Spring MVC. I have not used the latest versions, but the earlier versions of Spring MVC made you jump through a lot of hoops to get a web application running. I was almost sold on Lift until I saw that Lift can be very session dependent and would require 'sticky sessions' to work correctly. Excerpt from http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

我强烈考虑将 Lift 用于最近的 Web 项目，而不是 Spring MVC 的忠实粉丝。我没有使用过最新版本，但较早版本的 Spring MVC 使您在运行 Web 应用程序时遇到了很多困难。我几乎被 Lift 卖掉了，直到我发现 Lift 非常依赖会话并且需要“粘性会话”才能正常工作。摘自http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

Until there is a standard session replication technology you can still cluster you application using “sticky session”. This meas that all requests pertaining to a HTTP session must be processed by the same cluster node

在出现标准会话复制技术之前，您仍然可以使用“粘性会话”对应用程序进行集群。这意味着与 HTTP 会话相关的所有请求必须由同一个集群节点处理

So once a Session is required, the user would have to be pin to that node. This creates the need for intelligent load balancing and affects scaling, which prevented Lift from being a solution in my case. I ended up selecting http://www.playframework.org/and have been very pleased. Play has been stable and reliable so far and very easy to work with.

因此，一旦需要 Session，用户就必须固定到该节点。这产生了对智能负载平衡的需求并影响了扩展，这使得 Lift 无法成为我的解决方案。我最终选择了http://www.playframework.org/并且非常高兴。到目前为止，Play 一直稳定可靠，并且非常易于使用。

回答by Matei Alexandru Bogdan

In my humble opinion, imagination is what matters.

在我看来，想象力才是最重要的。

Let's consider you want to write an app. If you're a decent developer, the app should already be build in your mind. The next step is to discover how it works through code. In order to do that, you need to pass the imagined app through a function that translates it to a real world app. That function is a programming language. So

假设您想编写一个应用程序。如果您是一名体面的开发人员，那么您应该已经在脑海中构建了该应用程序。下一步是通过代码发现它是如何工作的。为了做到这一点，您需要通过一个函数将想象中的应用程序转换为现实世界的应用程序。该函数是一种编程语言。所以

Real app = programming language (imagined app)

So the language choice is important. So is the framework. There are a ton of smart people here that will advise you on what to chose, but ultimately, the language / framework that best translates your imagination should be your choice. So prototype with both and make your choice.

所以语言的选择很重要。框架也是如此。这里有很多聪明人会建议你选择什么，但最终，最能翻译你的想象力的语言/框架应该是你的选择。因此，使用两者进行原型设计并做出您的选择。

As for me, I'm slowly learning Scala and Lift and loving it.

至于我，我正在慢慢学习 Scala 和 Lift 并喜欢它。

回答by Rajith Delantha

But the main problem is we can't compare spring with lift. Lift is basically use as UI framework and Spring is use as DI framework.
If you are developing web app that does have that much of backend sure you can use lift.
but if your developing web app that have some series backend and you definelty need to goto spring.

但主要问题是我们无法将弹簧与升力进行比较。Lift 基本上用作 UI 框架，Spring 用作 DI 框架。
如果您正在开发具有那么多后端的 Web 应用程序，请确保您可以使用 Lift。
但是，如果您的开发 Web 应用程序具有一些系列后端并且您需要转到 spring。