类似于这个问题； When to use JavaScript template engines? 但不完全是。
在客户端 JavaScript 中使用诸如把手之类的模板引擎制作完整的网站（例如，跳过静态 HTML 和 PHP 处理，只发送带有 HTML 模板的 JavaScript 以进行客户端渲染）是否可行？或者，模板引擎是否仅在涉及可重用模板部分时才有用？
【问题讨论】：
标签： javascript templates template-engine
你有一半的答案，那就是重用，但你可以在服务器端得到它。对我来说另一半如下：
允许前端开发人员处理所有的 JS 和 HTML 交互开发，几乎无需了解 JS 即可满足简单的模板需求。
对于 Web 应用程序，服务器上的 UI 呈现会减慢或限制人们可以设计的交互/体验，或者至少会限制性能。为什么服务器必须知道并理解用户按钮的点击？浏览器功能强大，足以处理按钮点击。
它与 REST 服务完美搭配。浏览器知道如何请求数据并确定用户上下文。
更复杂的 Web 服务器端设计。状态是跨集群和节点管理的非常复杂的事情。不是你不能，而是你为什么要？特别是对于大多数现代 Web 应用程序（Web 2.0 和所有爵士乐）来说，重点是浏览器做的更多，处理按钮点击，对数据进行排序等。猜猜那是什么用户状态。所以浏览器已经有很多了。那么，为什么要在服务器集群中分配该状态，从而增加延迟、依赖关系等。我在应用程序服务器策略中没有 HTML。
更改控制。当您编写 PHP 并在所有内容中嵌入 HTML 片段时，事情最终会紧密耦合。它降低了用例更改的灵活性。
强制分离关注点。许多开发人员都想在视图中做业务逻辑。简单的模板有助于减少这种可能性。人们可以很容易地针对所有基于非模板的方法（JS 或服务器端）构建一个论据，但这不是当前的问题。
如果您要构建您想要的移动应用程序，并且需要避免演示标记的服务。所以永远不要在应用服务器中生成 HTML，否则你的应用只会说一种语言。人们可能会大喊服务器端 MVC 会有所帮助，但对于离线、不同的访问模式等没有帮助。
在服务器端生成 html 有一些性能、设备检测、“笨电话”原因，但随后将其从您的 JS Web 应用程序使用的服务中注销。让它成为例外。更好的做法是在服务端用 JS 编写，并在两者上重用业务功能和逻辑。
【讨论】：
我在制作单页网络应用程序时使用 JavaScript 模板引擎（例如使用主干.js）。
在任何其他情况下，我都不会使用 JavaScript 模板引擎。
这样做的原因是，如果我使用非纯 JavaScript（PHP、Rails 等）创建应用程序，我喜欢在服务器上而不是在客户端上完成模板。
【讨论】：