概念验证：玩！构架

我们正在开始一个新项目，我们必须选择Web框架。我们的默认选择是grails，因为团队已经拥有使用它的经验，但是我决定给Play！和Scala有机会。玩！有很多很酷的东西，在我的评估中，它得到了很多加分，但最终我们还是决定坚持下去。不是grails完美并且可以满足所有要求，而是Play！还不足以让我们切换。无论如何，这是玩的地方列表！我的评估不及格。如果我出了点问题，请纠正我：

模板引擎– UI开发人员对上一个项目中使用的模板引擎– freemarker感到愤怒，因为它不是null安全的–每当调用链中的null为空时，它就会崩溃。播放模板使用Scala，因此它们不是null安全的。 Scala使用不同的方法来处理null – Option，但是第三方库和我们的核心代码将使用Java，因此我们必须引入一些null到Option的转换，这将变得很丑陋。这个问题显示了处理该案件的方法，但是评论使我犹豫不决。这只是故事的一部分–出于对静态键入的敬意和敬畏，UI层必须使用一种简单的脚本语言。 EL / JSTL是一个很好的例子。如果找不到任何价值，它就不会爆炸。
静态资产– 这很难，而且我找不到有关使用Play的任何信息！ CDN或如何将多个资产合并到一个文件中。有没有简单的方法可以做到这一点？
IDE支持–唯一的编辑模板是通过scala编辑器，但它没有html支持。这不是一个大问题，但是围绕框架的工具是一件好事。
社区– Play！周围有一个很好的社区，但与grails相比，我认为它很好。玩！是一个较旧的框架，它对stackoverflow有2.5k个问题，而grails有7.5k个问题。
模块碎片化–我发现的一些重要模块仅适用于1.x，而不能在2.0中直接替换。

其他因素：

我不会使用它-UI开发人员会。尽管我对所有类型安全性和特殊的Scala概念可能都满意，但UI开发人员可能不会。
斯卡拉（Scala）丑陋-现在为此而ash惜我。是的，我不是一个斯卡拉的家伙，但这个是一个非常upvoted答案那种驱使我了。它看起来像是一种低级的编程语言，并且与上一点有关–对于我们的UI开发人员来说，它显然不适合。
更改编程模型–我提到Option vs null，但是还有很多其他事情。当然，这不是scala的问题，它甚至使它成为引起所有炒作的凉爽和好事，但是这是一个问题，太多的人将不得不同时改变他们的观点
我们已经大量使用了Spring和Spring-MVC，而Play与spring的集成不如Grails（在spring-mvc之上构建）那么流畅。
http://zeroturnaround.com/blog/play-framework-unfeatures-that-irk-my-inner-geek/

如您所见，许多问题并不普遍-它们与我们的经验和期望有关。您可能不需要使用CDN，并且您的UI开发人员可能是scala-gurus而不是普通的开发人员。正如我刚开始所说的，玩！绝对看起来不错，并且有很多很酷的东西，我在这里省略了（列表很长）。

参考： 概念证明：玩！ Bozho的技术博客博客中的JCG合作伙伴 Bozhidar Bozhanov的框架。