对于关于把手的菜鸟问题，我提前道歉。我来自 Rails 背景，虽然 Handlebars 看起来很酷，但我无法看到它比在服务器上编译视图的优势。
所以这里有问题。
目前，我们的应用程序在节点服务器上编译 Handlebars JS 模板，并将完全渲染的页面传回客户端。我被要求研究预编译模板以在客户端上呈现。
首先，我对如何构建它感到有些困惑。初始下载到客户端是否就像一个布局模板（只是样板 html、css 和 js），然后客户端将使用传递给它的任何 json 数据，以及位于 Handlebars.templates 中的预编译模板来构建意见详情？
如果是这样，用它可能需要的每个可能的模板加载客户端真的更有效，而不是只在它需要的时候提供它需要的东西吗？
【问题讨论】：
标签： node.js single-page-application handlebars.js precompiled-templates
首先，我对如何构建它感到有些困惑。初始下载到客户端是否就像一个布局模板（只是样板 html、css 和 js），然后客户端将使用传递给它的任何 json 数据，以及位于 Handlebars.templates 中的预编译模板来构建意见详情？
如果您正在做事情robustly，那么您将照常提供服务器呈现的页面。
这将包括一个<script>，其中嵌入了模板。它们仅在通常从服务器加载第二个页面时才开始播放。
如果是这样，用它可能需要的每个可能的模板加载客户端真的更有效，而不是只在它需要的时候提供它需要的东西吗？
初始加载需要额外费用。如果您的数据是合适的，那么从长远来看，这是值得的，因为您无需在每次访问基于相同模板的新页面时重新获取整个 HTML 文档（在某些情况下，所有更改都可以计算客户端一方面，您可以完全避免一些 HTTP 请求）。
【讨论】：
初始加载速度并不快。
但是，如果您正在做一个“单页”应用程序，那么初始加载后的每次更改都会更快。它会给人一种更有活力和快速的感觉。
但是，如果您使用表单做 rails，并且如果您不做类似应用程序的“单页”，那么就没有理由渲染客户端。
【讨论】：
这实际上取决于您的应用程序的特定需求和限制。客户端上模板的优势是减少了 http 请求并提高了性能。缺点是增加膨胀。因此，根据性能瓶颈所在的位置，与在初始有效负载中添加膨胀相比，增加 http 请求可能更好或更糟。当然，你可以懒加载模板包等等等等。
至于构建它，是的，您的模板正在客户端等待。当您从服务器请求 JSON 时，您将数据插入模板并呈现在页面上。
【讨论】：