你在Scala/Lift中有什么经验?
我最近听说了很多关于Scala和Lift Web框架的好东西,特别是Foursquare的人,因此,我可能会在下一个项目中使用这项技术。
- 你们是Scala/Lift开发人员吗?
- 你在这个平台上开发有什么经验,它比Ruby On Rails或Python/Django有什么优势?
- 你认为这是一项可行的技术,在未来几年里“值得关注”吗?
值得吗?在 Scala/Lift 平台上分享您的经验。
我最近听说了很多关于Scala和Lift Web框架的好东西,特别是Foursquare的人,因此,我可能会在下一个项目中使用这项技术。
值得吗?在 Scala/Lift 平台上分享您的经验。
我现在在Scala做我的大部分事情。(我应该提到,我认为Scala是自前段时间轮子发明以来最好的东西,:-D)
在我看来,它是唯一一种真正允许人们选择最佳任务方法的语言,而不会在(更多)面向对象和(更多)功能方法之间产生不必要的分歧。
看看之前声称像这样的东西的语言,我基本上可以看到两个相互竞争的语言设计阵营:
来自面向对象方面的人看到函数式编程最近获得了一些牵引力,并认为“好吧,我们并不真正理解函数式的东西,但是让我们在我们的语言中添加一些花哨的语法糖,这样我们就可以声称它也是函数式的!”(例如:Java,Python)
然后是那些来自函数端的人,他们认为“好吧,我们的函数式方法远远优于其他任何东西,面向对象的废话很烦人,但是让我们在我们的语言中加入一些额外的关键字,这将使我们的语言肯定逃离学术界!(例如:F#,OCaml)
Scala的设计者统一了来自双方的许多方法,并创造了一些精心设计的语言,在我看来,这是与其他语言的最大区别,其他语言决定采用“弗兰肯斯坦”方法来进行编程语言设计。
我只用Lift做了一些小事情,对Rails和Django只有肤浅的经验,我不得不承认,大多数时候,当我想知道为什么Lift中的某些东西与我的预期不同时,这是因为我的期望是有缺陷的,Lift的方法更优越。
Lift当然不是“轻松介绍Scala”,但学习Lift的工作原理几乎与学习Scala之前一样有益。
拥有没有任何逻辑的“干净”视图的能力是对其他框架的巨大改进,这些框架声称相同,但未能达到它。Scala的XML文字支持使得验证响应的正确格式成为可能:编译器将在编译时证明您只向客户端发出格式正确的XML。
Lift是可行的技术,目前是唯一真正的方法,如果你想构建看起来像“真实”桌面应用程序的Web应用程序,而不需要自己编写大量的代码。
我目前正在开发我的第二个Lift应用程序 - 它非常强烈地处于Lift的最佳位置 - 非常实时,很多并发性。
在与DB层摔跤几天后,我们放弃了第一个(现在更好了,我被引导相信),然后去了Play/Scala。这最大限度地利用了我们团队的现有知识,并有可能在最后期限内完成。但是,一旦我们的项目变得中等规模(PermGen一直用完 - 这是Scala编译的一个持续问题,几乎在任何地方)热代码重新加载几乎停止了,并且手动处理诸如网站中不同位置的方法调用参数和位置安全性之类的事情变得非常麻烦。当它完成时,我们很高兴 - 就像我倾向于找到Rails 1一样,随着项目规模的增加,速度增加会缩小,到最后,它就像在Velocity /Spring/ XML ++中工作一样乏味和容易出错)。
这一次,我们一直致力于弄清楚Lift是如何做到的,以及正确的做事方式。这意味着要随意浏览邮件列表(几个版本旧的讨论通常仍然相关),最重要的是团队的新精神。有必要非常强烈地内化座右铭:
“这感觉很难和重复。我敢打赌,他们用一种更简单的方法做到了这一点。
到目前为止,Lift从未让我们失望过。顺便说一句,我不是在谈论像站点地图和列表串联语法这样的东西 - 你必须对功能性的Scala有一个很好的处理,否则你将无法阅读源代码,甚至无法配置你的应用程序。
也就是说,这不是疯狂的IO monads或任何东西,只是一些常见的习语,无论如何,你会在Scala的几个星期内学会。
对我们来说,最大的问题是编译周期缓慢。大约需要20秒才能运行我们的项目,这与Play(当它工作时)热编译你所有的东西是不同的感觉。另一方面,我们实际上在前几天当我们的一位开发人员抱怨它时,我们发现尽管Play在技术上是热编译的,但页面仍然需要12秒才能在Dev模式下加载。所以没有巨大的损失,只是感觉有点慢,不得不跳到命令行。
Lift可以让你做很多事情,在我们的应用程序中有很多地方(因为它可用),我们已经说过“是的,我们真的希望立即向该页面的所有查看者更新实时更新,而不是他们后来发现它们已经过时了(想想你同时发布到SO上的人的所有时间, 答案相同)。事实证明,彗星无处不在 - 它不是一个专业的用例,而是事情应该工作的方式。Lift使它变得非常容易。
我们也喜欢强大的,可编程可配置的安全模型 - 一旦我们将思维方式切换到“我们必须将每个位置列入白名单,并指定必要的入口条件”,我们从未见过另一个会话问题 - 你知道,那些你认为用户会遍历特定路径,因此会知道一大堆参数的问题?比如,一个有效的用户名,一个感兴趣的领域或其他什么?(我故意含糊不清)。这可能是有状态框架的尴尬之处之一,当用户点击页面时,您将希望具有可用状态,而不是(例如)只是要求在每个请求中都执行所有状态。
我从Lift的这个新镜头中得到的收获:
这是值得的。不仅要构建你尝试构建的应用,还要构建你不知道自己需要的应用。
有很多挠头,但没有很多代码。当它工作时,它确实有效。它快速,干净,对于它在浏览器和服务器之间工作的所有奇迹,我从未见过它变得混乱。