我最近听到了很多关于Scala和Lift Web框架的好消息，特别是来自Foursquare's guys因此，我可能会在我的下一个项目中使用这项技术。
值得吗？分享您在Scala / Lift平台上的体验。
答案 0 :(得分：28)
我现在正在Scala做我的大部分事情。 （我应该提一下，我认为斯卡拉是不久前发明轮子以来最好的东西。： - D）
在我看来，它是唯一真正允许人们选择最佳方法来完成任务的语言，而不会在（更多）面向对象和（更多）功能方法之间产生不必要的分歧。
看看以前声称有类似内容的语言，我基本上可以看到两个相互竞争的语言设计阵营：
来自面向对象方面的人看到函数式编程最近获得了一些牵引力并且认为“好吧，我们并不真正理解那个功能性的东西，但是让我们为我们的语言添加一些花哨的语法糖，所以我们可以声称它也很实用！“ （示例：Java，Python）
那些来自功能方面的人，他们认为“嗯，我们的功能方法远远优于其他任何东西，而且面向对象的废话很烦人，但是让我们在我们的语言中添加一些额外的关键词，这将使我们的语言肯定会逃离学术界！“ （例如：F＃，OCaml）
Scala的设计师统一了来自双方的许多方法，并创造了一些精心设计的语言 - 在我看来，这是与其他语言的最大区别，后者决定采用“Frankenstein”方法进行编程语言设计。 / p>
只使用Lift做了一些较小的东西，只有Rails和Django的表面经验，我不得不承认，大部分时间我都想知道为什么Lift中的某些东西与我的预期有所不同，这是由于事实上，我的期望是有缺陷的，而且Lift的方法更优越。
Lift当然不是“Scala的简单介绍”，但学习Lift如何工作几乎和学习Scala一样有价值。
能够拥有一个没有任何逻辑的“干净”视图的能力是对其他框架的一个很大的改进，这些框架声称相同，但没有达到它。 Scala的XML文字支持使得验证响应格式良好成为可能：编译器将在编译时证明您只向客户端发出格式良好的XML。
Lift是一种可行的技术，目前唯一真正的方法，如果您想构建外观，感觉和行为类似于“真实”桌面应用程序的Web应用程序，而无需自己编写大量代码。
< / LI>答案 1 :(得分：9)
我正在开发我的第二个Lift应用程序 - 它在Lift的最佳位置非常强烈 - 非常实时，很多并发。
第一个我们在与DB层摔跤几天之后吵醒了（现在好了，我被引导相信），然后去了Play / Scala。这最大化了我们团队的现有知识，并使截止日期成为可能。但是，一旦我们的项目变得适度大（PermGen不断运行 - 这是Scala编译几乎无处不在的问题），并且在不同的地方手动处理方法调用参数和位置安全等问题，热代码重新加载几乎停止了。在网站上相当繁琐。当它完成时我们很高兴 - 就像我倾向于找到Rails 1一样，随着项目规模的增加，速度增加了，并且到最后它在Velocity中工作时变得乏味且容易出错。 Spring / XML ++等等。
这一次，我们一直致力于研究Lift如何做它所做的事情以及正确的做事方式。这意味着要通过邮件列表进行大量的随意浏览（多个版本的讨论通常仍然相关），最重要的是团队的新精神。有必要非常强调内容：
“这种感觉很难并且重复。我敢打赌，他们更容易做到这一点。”
到目前为止，Lift从未让我们失望过。顺便说一下，我不是在谈论Sitemap和列表连接语法之类的东西 - 你必须对功能Scala有一个非常好的处理，否则你将无法阅读源代码甚至配置你的应用程序。
那说它不是疯狂的IO monads或者其他东西，只是在Scala的几周内你会发现的一些常见的习语。
我们面临的最大问题是编译周期缓慢。跳船需要大约20秒钟：运行我们的项目，这是一种与Play不同的感觉（当它正在工作时）热编译你所有的东西。另一方面，我们实际上是在我们的一个开发者抱怨它的那一天，并且它确定尽管Play技术热门编译它，但页面仍然需要12秒才能在开发模式下加载。所以没有太大的损失，只是感觉有点慢，不得不跳到命令行。
Lift让你做了很多事情，我们的应用程序中有很多地方（因为它可用），我们已经说过“是的，我们真的希望将该实时更新立即更新到该页面的所有观众，而不是他们后来发现他们已经过时了（想想你在SO上同时发布的所有时间，同样的答案）。COMET无处不在，事实证明 - 它不是专家用例，它是事情应该如何运作。而Lift让它变得非常简单。
我们也喜欢强大的，可编程配置的安全模型 - 一旦我们将思维模式转换为“我们必须将每个位置列入白名单，并指定必要的入口条件”，我们从未见过另一个会话问题 - 您知道吗，那些你假设用户会遍历某条路径，因此会知道一大堆参数？比如，有效的用户名，感兴趣的区域或其他什么？ （我故意模糊）。这可能是关于有状态框架的尴尬事情之一，当用户点击页面时，您将希望具有可用状态，而不是（例如）要求所有状态在每个请求中被携带。
我对Lift的重新拍摄的结果：
值得的。不只是构建您正在尝试构建的应用程序，而是构建您不了解所需的应用程序。
有很多头疼，但不是很多代码。当它工作时，它确实有效。它快速，干净，而且对于浏览器和服务器之间的所有奇迹，我从来没有看到它混淆。
答案 2 :(得分：7)
我在Lift开发企业财务应用超过6个月，我是JAVA程序员前者。我注意到了几点，这可以帮到你：
我写了明显较少的代码行（great example）
在Lift附近，有一种非常友好的community。他们总是试图提供实质性的答案。我没有任何糟糕的经历。即使他们愿意为Lift中的新功能提供新建议。他们批准了我的两条建议！
每隔6到8周宣布一次新的稳定次要版本的Lift。新里程碑每两周定期举行一次。
Lift是Web应用程序的绝佳框架。你可以阅读大约七main features的升力。
提升默认ORM模块 - Mapper不适用于具有大量外键和约束的大型和高级数据库模型。我们不得不使用Squeryl。
我无法想象我现在必须返回JAVA代码。但我的小建议是尝试编写一些简单的应用程序，你会看到。