你说的模板引擎应该是指后端模板引擎。从网站全栈开发程序员的角度来看：从前，前端[不考虑原生app]只要“哄好”浏览器（包括微信内嵌的、app内嵌的）就可以了，服务端都是Nginx/Apache/IIS + php（大部分程序依赖于php-fpm[不能常驻内存]，少量运行在CLI[也就是命令行]），大家都用MVC, 都在热烈讨论视图文件与模板引擎的“家长里短”。后来，前端爆出了“微信小程序”，不少前台页面“弃暗投明”，好在后台页面/对/浏览器/“忠心耿耿”。再后来，swoole异军突起，php可以常驻内存、运行速度“风驰电掣”，同时开发方式大变[大部分运行在CLI]，比如：echo会输出到终端而不是浏览器---然而，模板引擎都是用echo输出动态数据到浏览器的---这就尴尬了。
现在，访客的客户端既有小程序，又有浏览器。小程序的页面只能由js渲染，php模板引擎对小程序页面无可奈何。php接口不得不设计为API，以便返回json给小程序，这种API倒是可以加以包装，这样，浏览器那边的前台页面可以继续使用模板引擎。后台页面，直接使用模板引擎。
一但用上swoole，要是坚持使用模板引擎，由于模板引擎将视图文件(view.html)翻译成模板文件（tpl.php），都会用到“echo”，（如果用到的视图文件都没有修改过，就直接）include tpl.php之后，为了防止输出到终端，使用ob_get_clean(), 再使用swoole的接口输出到浏览器，
倒也是可以。
结论：
后端模板引擎，只是开发一时爽，不适宜团队合作，适合全栈开发者，缺点：
应变能力差：使用全新装修的话，后端开发就要套页面，繁琐。
浪费人力资源，加重后端团队的负担：前端折腾完html页面，后端需要经手一遍。不得不提一点：分页条。thinkphp框架的分页条是写在php的page类里面，如果分页条样式变了，前端写完html代码，后端要誊写一遍。
如果需要翻译视图文件，则后端负担相对较重，用户等待时间相对较长：比如：编辑数据的页面。php从数据表里边拉取到数据，已经仁至义尽了，却还要翻译html文件，即使不用翻译，也需要查看用到的视图文件是否修改过。
后端模板引擎的渲染是一次性的，而前端模板引擎可以反复渲染，利于沉浸式体验。同一段html代码，要么由后端模板引擎循环处理，要么由前端模板引擎循环处理。举个例子：进入购物车页面（/cart/index），对某个商品重新挑选促销方案后，该商品需要挪到新的分组，再次计算受影响的组的优惠、赠品，然后再次计算总优惠。（后端更改促销方案, 不应由/cart/index处理，不然就“千人排、万人坑”，越来越“牵一发而动全身”。） 假设是由/cart/selectPromotion处理， 如果使用前端模板引擎，即便反复挑选，页面也无需刷新，不会打断沉浸式体验，否则，等待转圈结束，页面还要需要刷新，页面无论如何都是要经历空无一物的白色，反复刷新几次，真的沉浸不下来。
由于css样式的影响，部分php错误信息未能及时发现，直到：打开控制台，查看源码，偶然看到额外的html元素直接查看网页源码，看到额外的html元素js出错：比如说，取不到指定html元素，json字符串转换成对象失败。好处：
共同的html可以抽出来作为公用文件，用php加载公用文件。
可以用php读取静态文件的上次修改时间，引入静态文件时，将这个时间作为版本号，静态文件有变化则重新请求，否则使用本地缓存。调试过程中，不需要同时按shift + F5, 也不需要手动更改版本号，比较省事。
纯静态页面+ajax：适宜团队合作，也适合全栈开发者，应变能力强，不会浪费后端的人力资源，php负担相对较轻，用户等待时间相对较短，体验更好，除了开发时繁琐了点。
