后端模板引擎的适用场景是什么？

Question

用 nodejs 的模板引擎开发后端渲染的页面，能够做到改了页面的 html，css，浏览器自动刷新吗？有什么现成的解决方案吗？如果不能，那模板渲染的开发方式不是很鸡肋吗？它和 SPA 应用相比处于什么位置？想要同时获得 SPA 的开发体验和服务端渲染的时效性，只能指望 SPA 框架的服务端渲染吗？
感觉重前端逻辑的开发，后端模板渲染处于一个很尴尬的地位。那它只用于轻前端逻辑的简单页面吗？

Answer 1

我们最近官网在搞SEO优化，身为一个后端，来说一点自己的想法。

1. 使用模板引擎来开发，自动刷新应该会慢一点(至少java是这样的，比不上SPA)，不过的确是能做的(自动重启)
2. 我们前端说用的是nuxtjs，也可以做到SSR(服务器端渲染)
3. 后端的模板引擎其实用的很少了，应该算是被分离出去给前端替代掉了，用SPA的方式开发，然后用SSR的方式去部署，挺好的呀
4. 现在前端也在走高度工程化，各种框架概念满天飞；这种（模板引擎）前后端耦合的开发方式肯定是前端不愿意看到的啦

所以模板引擎应该是会慢慢消失的吧，大概，可能，也许。

Answer 2

浏览器自动刷新什么的是 webpack 做的事情，webpack又是基于node。模板引擎开发是最早开发模式，比如：PHP需要前端切页面。所以前端被称为切图仔。

Answer 3

1. 在 MVVM 框架出现之前，SPA 实现难度不小，后端渲染是主流
2. 后端渲染可以更好的满足 SEO 需要
3. 你说的不错，如果很重前端交互，那么后端渲染价值不大

总结起来，目前的后端模版引擎适用于有高 SEO 要求，同时前端交互比较轻的产品，比如媒体类、内容类，甚至包含 SF 这样的问答类。

Answer 4

“想要同时获得 SPA 的开发体验和服务端渲染的时效性”，你可以使用 SPA 框架开发，然后开启服务端渲染。
需要注意的是，后端模板引擎其实有一些缺陷，比如脚本的重复初始化等问题，这样的问题通常不会在项目初期显现出来，而服务端渲染会继承并将这些缺陷发扬光大，因为开发人员有时候会忘了界定哪些逻辑要放在前端，哪些要放在后端，这种问题在重前端逻辑的情况下会尤其明显。因此，重前端逻辑的开发，除非是小团队小项目沟通成本低，慎用后端模板引擎和服务端渲染，最多就是作首屏来提高一下用户体验和 SEO，首屏渲染之后的事情交给前端。
浏览器热更新这个事情跟 SPA 没有啥关系，其原理就是后端 watch 相关文件的更新，然后通过 webSocket 通知页面刷新一下，好点的前端可以通过魔改 SPA 官方脚手架搞定，作为后端即便不想学 webpack ，手撸一个类似的自动刷新机制应该不是难事。