从他们的网站http://www.playframework.org/documentation/1.0/faq
” 目前，Play堆栈中最大的CPU使用者是基于Groovy的模板引擎。但是，由于Play应用程序可以轻松扩展，如果您需要提供非常高的流量，这不是一个真正的问题：您可以平衡多个服务器之间的负载。我们希望通过新的JDK7以及对动态语言的更好支持，在此级别上获得性能提升。 “
所以没有更好的选择？ JSP怎么样？
答案 0 :(得分：12)
JSP不可行，因为每个JSP都编译为Servlet，而servlet API提供的服务器端会话与RESTful范例不兼容。我们不想回到可扩展性差的服务器端会话的黑暗时代，回到浏览器中的按钮问题，重新发布等等。
Japid模板很有意思，但它们没有一个伟大的社区支持，甚至可能在创建游戏时甚至不存在（我不确定）。我在我自己的应用程序中尝试使用Japid作为Groovy模板的替代品，并在JMeter测试中发现，这种好处只是微不足道的，10％到最大值。提高25％。
我想最终这一切都取决于您的可扩展性要求和页面结构。我选择了应用程序的90％用例并进行了测试。对我来说，这个小改进并不能证明额外依赖的额外成本（我喜欢将依赖关系保持在可维护性的最低限度）。
Groovy模板一般不坏或慢。尽可能使用类型变量（而不是“def”），即使在闭包中也是如此！将访问属性的值保存在局部变量中。分页做得合理。然后保持你的手指交叉，以后GSP可以在groovy ++上运行，你就完成了;）
对我来说，问题不在于他们在观点中使用groovy的原因。也就是说，因为我宁愿在控制器层中错过它。 Groovy会使控制器行为编码变得更容易恕我直言。
答案 1 :(得分：8)
首先，JSP不是Play的有效选项，因为它选择不沿着Java EE路由（JSP是其中的一部分）。相反，Play选择使用Groovy作为一个直观，简单但功能强大的模板引擎。
然而，Play最大的特点之一是它是一个可插拔的系统，这意味着可以简单地替换核心系统的许多部分。这包括模板引擎，还有一些已经可用。
最受欢迎的是Japid。它声称比标准模板引擎快2-20倍，并且已经存在了一段时间。有关详细信息，请参阅此处http://www.playframework.org/modules/japid。
第二种选择是剑桥，虽然这只是暂时的，但在留言板上相当活跃（见https://groups.google.com/forum/?hl=en#!searchin/play-framework/cambridge/play-framework/IxSei-9BGq8/X-3pF5tWAKAJ）。
我倾向于坚持Groovy，因为我喜欢它的工作方式，并且没有发现它在性能方面太糟糕，但每个应用程序都是个性化的，所以你自己的性能测试应该引导你自己的特定路径。
答案 2 :(得分：4)
是的，有Japid。哪个更快，更快。
答案 3 :(得分：2)
我完全同意Play Framework设计师在这里选择的轻松超速。我的猜测是，如果模板开始妨碍性能，你可以（并且应该！）测量慢位，并在可能的情况下将它们重构为快速标签。通过这种方式，您可以通过将20％移动到快速标签中来节省80％的CPU，从而为您提供灵活性和足够的速度。
话虽如此，我期待着一个实验，我正计划看看新的Scala模板（从Razor.NET中松散地“借用” - 非常干净的语法）与Java控制器/模型的协作能力。 Scala后端在比较轻松方面尚不存在，但模板语言肯定会摇滚。
答案 4 :(得分：0)
我可能会在2016年迟到派对.Play 2已经淘汰，而JDK（更不用说硬件）也大幅提升了。我没有使用Play或Spring Boot，因为我的平台并不需要它们 - 只需从模板中生成纯运行时文本/ HTML。
首先，在谈论Groovy模板时，不止一个。我使用原始的Groovy SimpleTemplateEngine来处理从电子邮件到丰富网页的任何内容，无论现在大多数人都喜欢“高级”＃34; MarkupTemplateEngine及其非HTML构建器语法。我没有走这条路，因为IDE（例如UntelliJ）支持使用JavaScript的JSPish HTML文件 - 捕获未封闭的标签，大括号等。此外，如何将JavaScript包含在基于花括号的＃34; builder＆＃34;样式模板？
无论您选择哪种方式，SimpleTemplateEngine和MarkupTemplateEngine都会静态编译其模板，即使Groovy doc仅为后者提及它。为什么它不能为前者创造一个类？我没有将它们相互比较，但是我希望SimpleTemplateEngine更快，因为它更好 - 更简单 - 不会将任何语法转换为带有ifs和loop的字符串连接之间。
确实非常快。我担心在循环中调用它。没有任何区别。没有开销，因为模板编译一次。
我使用多个小模板负责生成单独的表单控件标记（HTML + JS）以生成复合表单，包含在更高级别的容器中，包含在另一个容器中，依此类推，直到整个页面形成。正如您已经猜到的那样，分解您的视图使其成为模块化，封装和面向对象的＃34; - 由许多相互构建的单独MVC组件组成。有点好的旧自定义JSP标签，只在运行时进行评估，并与Spring Boot等技术兼容，如果你无法抗拒时尚的简历提升类似的东西。
具有100个字段的测试表单（所有复杂的＆＃34;智能＆＃34;具有封装状态管理和行为的控件）首次在150ms内呈现，然后在10-14ms之后呈现。在我的内存饥饿的4y.o上的IDE调试器中。笔记本。我还验证它是线程安全的，因为Groovy从未明确提到它。如果它被编译成与其他任何其他无状态Groovy类一样，为什么不会呢？调用createTemplate（）一次，将模板存储在某处，并在servlet或其他并发上下文中使用它（调用Template.make（））。显然，我在实际应用程序中永远不会有100字段的形式。任何人都需要重新考虑他/她的用户体验。
表现相当充足。我甚至接受一秒钟来渲染一个100字段的页面。想一想，在Web应用程序中，您不需要最终的纳米导弹或核导弹跟踪性能。如果你这样做，选择生成Java类的Jamon：http://www.jamon.org/Overview.html，你通常会编写连接字符串。我没有测试它，因为我不喜欢额外的编译步骤（由Maven自动执行，但仍然）。与编译的，是的，强类型的Java相比，编译的Groovy字节码对我来说已经足够了。除非你做一些复杂的事情，否则差异将是微不足道的，你不应该在模板中（见下文）。按照此线程中的建议使用类型化的Groovy变量与def，只在该100个模板运行中保存了几毫秒。
模板不应该有太多的程序逻辑（内部变量，ifs和循环） - 这是控制器的责任，而不是视图的责任。也就是说，ifs和循环是模板引擎必须的。如果他/她可以简单地调用String.replace（）？
，为什么会使用Handlebars / Moustache？其余的模板引擎也无关紧要。没有字符串连接（例如Velocity，或Freemarker）或基于JS的解释技术（例如Jade）将在性能方面击败最直接的Jamon方法。作为一名Java程序员，您希望使用自己喜欢的语言/语法：直接（Jamon）或90％接近Java，Groovy是（以脚本为中心的简洁解释Java）。我不会评论Scala - 偏好问题。除了据称＆＃34;简洁＆＃34;语法（与Java 8+越来越不相关）需要付出代价。而且只对复杂的循环有用。您不希望在一个模板中编写整个应用程序，就像我已经说过的那样。几个循环，最多十个if语句最多
而且，就像所有人提到的那样，直观的语法和易用性是关键。它们大大减少了错误的数量。一个好的（额外的）服务器花费1000美元，而开发人员的工资 - 用于修复因边际性能优化的复杂性而产生的所有错误，要高出100倍。