我即将选择组织我的观点（使用spring-mvc，但这不应该太重要）
据我所知，有6个选项（尽管它们并不相互排斥）：
<jsp:include> <%@ include file=".."> Tiles 和 Sitemesh 可以分组; Freemarker 和 Velocity 也可以。每个小组中使用哪一个不是这个讨论的问题，有足够的问题和讨论。
This is an interesting read，但不能说服我使用瓷砖。
我的问题是 - 使用 <@ include file="..">和JSTL无法正确完成这些框架提供的内容。要点（一些来自文章）：
包括部分页面，如页眉和页脚 - 之间没有区别：
<%@ include file="header.jsp" %>
和
<tiles:insert page="header.jsp" />
在标题中定义参数 - 如标题，元标记等。这非常重要，尤其是从SEO的角度来看。使用模板选项，您只需定义每个页面应定义的占位符。但是你可以在jsp中使用 JSTL ，使用<c:set>（在包含页面中）和<c:out>（在包含的页面中）
布局重组 - 如果要在菜单上方移动面包屑，或在另一个侧面板上方移动登录框。如果页面包含（使用jsp）组织不当，则可能需要在这种情况下更改每个页面。但是如果您的布局不是太复杂，并且您将常见的东西放在页眉/页脚中，则无需担心。
公共组件和特定内容之间的耦合 - 我没有发现这个问题。如果要重用某些片段，请将其移动到不包含任何页眉/页脚的页面，并在需要的地方包含它。
效率 - <%@ include file="file.jsp" %>比其他任何内容都更有效，因为它只编译了一次。所有其他选项都经过多次解析/执行。
复杂性 - 所有非jsp解决方案都需要额外的xml文件，其他包括，预处理器配置等。这既是学习曲线又是引入更多潜在的失败点。此外，它使支持和更改变得更加乏味 - 您必须检查许多文件/配置以了解正在发生的事情。
占位符 - 速度/ freemarker是否提供了比JSTL更多的东西？在JSTL中，您放置占位符，并使用模型（放置在请求或会话范围内，由控制器）来填充这些占位符。
因此，说服我除了普通的JSP之外，我应该使用上述任何框架而不是/。
答案 0 :(得分：17)
Velocity的一些论据（我没有使用过Freemarker）：
占位符 - 速度/自由制作者提供的东西比JSTL更多吗？在JSTL中，您放置占位符，并使用模型（放置在请求或会话范围内，由控制器）来填充这些占位符。
是的，references确实是VTL的核心：
<b>Hello $username!</b>
或
#if($listFromModel.size() > 1)
You have many entries!
#end
效率 -
<%@ include file="file.jsp" %>比其他任何东西都更有效率，因为它被编译一次。所有其他选项都被解析/执行多次。
不太确定我同意或理解这一点。 Velocity有一个缓存模板的选项，这意味着它们被解析的抽象语法树将被缓存而不是每次从磁盘读取。无论哪种方式（而且我没有这方面的实数），Velocity总是觉得快对我来说。
布局重组 - 如果要在菜单上方移动面包屑，或在另一个侧面板上方移动登录框。如果页面包含（使用jsp）组织不当，则可能需要在这种情况下更改每个页面。但是如果你的布局不是太复杂，并且你把常见的东西放在页眉/页脚中，就没什么可担心的了。
不同的是，使用JSP方法，您不会在使用相同页眉/页脚的每个JSP文件中重新组织此布局吗？ Tiles和SiteMesh允许您指定基本布局页面（JSP，Velocity模板等 - 它们都是JSP框架），您可以在其中指定所需内容，然后委托主内容的“内容”片段/模板。这意味着只有一个文件可以移动标题。
答案 1 :(得分：11)
jsp:include和 Tiles / Sitemesh / etc 之间的选择是开发人员一直面临的简单性和强大之间的选择。当然，如果您只有几个文件或者不希望您的布局经常更改，那么只需使用jstl和jsp:include。
但是应用程序有一种逐步增长的方式，并且很难证明“停止新开发和改进瓦片（或其他一些解决方案），以便我们可以更轻松地解决未来的问题”，如果您在开始时没有使用复杂的解决方案，那么这是必需的。
如果您确定您的应用程序将始终保持简单，或者您可以设置一些应用程序复杂性的基准，之后您将集成一个更复杂的解决方案，那么我建议不要使用tile / etc.否则，从一开始就使用它。
答案 2 :(得分：4)
我不会说服你使用其他技术。据我所知，如果适合他们，每个人都应该坚持使用JSP。
我主要使用Spring MVC，我发现 JSP 2+与SiteMesh 完美匹配。
提供应用于视图的装饰器，就像其他模板引擎中的继承一样。如今没有这种功能是不可想象的。
人们声称JSP会让模板中的Java代码难以避免，这是假的。你不应该这样做，而且这个版本没有必要这样做。版本2支持使用EL调用方法，与以前的版本相比，这是一个很大的优势。
使用 JSTL 标记，您的代码仍然看起来像HTML，因此不那么尴尬。 Spring通过taglibs为JSP提供了很多支持，这非常强大。
taglibs也很容易扩展，因此自定义您自己的环境是轻而易举的。
答案 3 :(得分：2)
facelets的最佳参数之一（不在你的列表中，但我只是提到它）反对使用JSP是编译与解释器集成而不是委托给JSP编译器。这意味着我使用JSF 1.1时最烦人的事情之一 - 在保存更改以便运行时引擎发现更改时，必须更改周围JSF标记的id属性 - 消失了，给出了保存 - 编辑器内，重新加载浏览器循环返回，以及更好的错误消息。
答案 4 :(得分：2)
一个好的视图技术消除了大多数最烦人的if / switch /条件语句，简单包括没有。使用“复杂”视图技术可以实现“简单”的应用。
答案 5 :(得分：1)
您未提供有关特定应用程序的信息。例如，我之所以不使用JSP只是出于以下几个原因：
很难避免在JSP模板中使用Java代码，因此您的纯视图的破坏概念，因此您将难以在视图和控制器等几个地方维护代码
JSP自动创建建立会话的JSP上下文。我可能想避免它，但是如果您的应用程序总是使用会话，那么对您来说可能不是问题
JSP需要编译，如果目标系统没有Java编译器，任何小的调整都需要使用其他系统然后重新部署
最小的JSP引擎大约有500k的字节码加上JSTL，所以它可能不适合嵌入式系统
模板引擎可以生成相同模型的不同内容类型，比如JSON有效负载，网页，电子邮件正文，CSV等。
当非技术人员从未遇到修改常规模板的困难时，非Java程序员可能难以使用JSP模板。
我很久以前就问过同样的问题，最后编写了我的框架（当然是基于模板引擎），它没有我在其他解决方案中看到的所有缺点。不用说它是大约100k的字节码。
答案 6 :(得分：0)
我意识到这是一个聪明的答案，但事实是，如果你没有看到在当前项目中使用模板代码的任何优势，那可能是因为在你当前的项目中，没有不是。
部分内容涉及规模。你可能会认为包含的东西就像让我们说sitemesh一样强大，这肯定是正确的，至少对于少量的页面（我说可能大约100个），但是如果你有几千个它开始变得无法管理。 （因此，对于eBay来说，没有必要，对Salesforce来说可能是这样）
另外，如前所述，freemarker和velocity不是servlet特有的。您可以将它们用于任何事情（邮件模板，离线文档等）。您不需要Servlet容器来使用freemarker或velocity。
最后，你的观点5只是部分正确。每次访问它时都会编译它，如果还没有这样的话。这意味着无论何时更改某些内容，都需要记住删除servlet容器“work”目录，以便重新编译JSP。使用模板引擎时，这是不必要的。
TL; DR 编写模板引擎是为了解决JSP + JSTL的一些（感知的或真实的）缺点。是否应该使用它们完全取决于您的要求和项目规模。