遊
你說的模板引擎應該是指後端模板引擎。從網站全棧開發程序員的角度來看：從前，前端[不考慮原生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負擔相對較輕，用戶等待時間相對較短，體驗更好，除了開發時繁瑣了點。
