脚本标签中的客户端模板。优点缺点？

Question

只是对将单页 Java 应用程序的客户端模板放在 HTML 文件的脚本标记中的当前趋势感到好奇。似乎是一种有趣的方法，但这是否被认为是最佳实践（或至少是更好的实践）？我试图列出优点和缺点的清单，但坏处似乎超过了好处。 所以我的看法是这样的：

优点：

1. 获取所有模板只需一个请求，而每个模板文件需要一个单独的异步请求。

缺点：

1. 如果所有模板都在一个位置，则创建一个潜在的合并故障点/瓶颈文件
2. 在一个文件中编辑模板有点麻烦
3. 与使用键盘快捷键打开文件相比，查找所需模板有点麻烦。
4. 必须等到 DOM 准备好之后才能对模板进行任何操作。

似乎通过将它们放在脚本标签中，您可以预编译和缓存您的模板，因此您只需查询一次 DOM 即可获取每个模板。但是，您不能使用 AMD / Require 和 require/text 来达到相同的效果吗！还是道场/文本！？在后一种情况下，您只会懒惰地加载每个模板一次。然后你可以缓存它并在那时预编译它。

我只是很难在脚本标签中看到模板的许多优点。我错过了什么吗？

Answer 1

恕我直言，这实际上取决于您拥有多少模板。当您的网站刚开始并且没有很多模板时，将它们全部放在单个 HTML 页面上的 script 标记中很有意义。

但是，随着模板数量的增加，这很快就会变得笨拙；不久之后，您将使用服务器端逻辑将一堆单独的模板文件连接到您的主 HTML 文件中，此时我认为开始考虑其他方法非常有意义。

就我个人而言，我公司的代码库从 HTML 文件中的 script 标签开始，但随着我们的成长（并开始使用 require），现在我们有数十个甚至数百个 .handlebars（或更多）通常，我们所有模板的 .hbs) 文件。我们使用 Alex Sexton 的 HBS 插件 (https://github.com/SlexAxton/require-handlebars-plugin) 将这些引入到我们的 Javascript 中，这很有效，因为：

1. 我们可以将标准require 系统用于我们的模板
2. 当我们使用 require 优化器时，模板会被编译成一个压缩的 JS 文件
3. 我们可以将 IDE 配置为将 .handlebars 文件视为 HTML，从而在我们编辑它们时为我们提供适当的语法着色等

我不确定您使用的是哪个模板系统，但如果您正在使用 Handlebars 并且已经在使用 Require，那么 HBS 插件是一个很好的方法。如果您使用不同的模板系统，您可能会为 Require 找到类似的插件（如果该系统足够流行），甚至可以使用 HBS 作为基础编写自己的插件。

对于拥有大量模板的任何人，我认为这样的系统（尤其是对于已经使用 Require 的任何人）比script 标签更有意义。

Answer 2

如果我对您的理解正确，您有一些要使用的客户端模板，但您想在服务器端将它们分成单独的文件。当您拥有大量此类模板时，这种方法具有一些明显的工程优势。

您可以考虑使用 JSONP。在服务器端使用半体面的处理程序，您将获得您正在寻找的好处：

1. 每个模板的单独文件
2. 轻松包含在您的 HTML 页面中。
3. 能够将每个模板分配给一个变量，或在客户端收到模板后立即通过编译函数发送它。
4. 在客户端缓存模板，因此不必为每个页面重新加载。
5. 与缓存代理的兼容性

JSONP 实现中唯一重要的部分是缓存属性。您需要确保接收请求的服务器端控制器了解条件 GET、如何发送 304 响应以及正确设置缓存标头。

如果您不熟悉该技术，可以查看JSONP wikipedia entry。