隨著前端 MVC， MVVM 框架的壯大，後端模版引擎是否可以退出歷史舞台了？
因為原本應該在後端進行模版渲染的工作都轉向了前端 MVC ， MVVM 框架來做，後端只需要從模型層提取輸出 json 或者 xml 數據給前端，這樣的話，網站的框架基本已經成為 MCMVC ，也就是 MVC 中的 V又等於 MVC ？
我覺得這樣對前後端的分離將會更加徹底，前端人員不再需要學習模版引擎這種怪異的類編程語言，而且模版引擎帶來的性能損失也全部轉移給了客戶端，這樣可以大大減少伺服器壓力，缺陷當然也是有的，前端的工作量又要多了一點。。。你們是怎麼看？——————————修改一下問題，我想說的是後端模版引擎（比如說smarty）是否快到可以退出歷史舞台的時候了？
你說的是不用 WebServer 輸出 html 了，輸出格式化的數據就好，前端做數據渲染的工作，這個沒錯。也是一個不錯的解耦做法。
從 單純『Web 前端』的角度，也許會認為『後端模版引擎』沒用途了，可以『退出歷史舞台』。
但是，從工程的角度，『後端模版引擎』能做的事情，遠不只這些。比如，在渲染郵件，渲染配置，自動生成代碼，等等。
所以，答案是：不會。
另外，『模版引擎這種怪異的類編程語言』，不是複雜的東西，技多不壓身，『前端人員要掌握的東西』太多了，再多一個又何妨。
謝邀。答案是：一般是不可能的。
1. 模板引擎跟後端語言如Python、PHP還是相關聯的。也就是能夠更加方便地搭配使用。模板引擎的重點角色往往是簡單數據攜帶及其簡單處理，而各種前端框架的意義現在往往動不動就是工程概念、組件構建，層次上兩者不可同日而語；
2. 其實這個問題的更深層次是「SPA以後是不是會佔據主流」？應該不會，雖然好比你可以考慮用Go作為API和JSON數據提供方，JS處理前端邏輯及AJAX通信，但SPA不可能滿足一切應用場景。謝邀！
對後端了解不多，如果說錯了，不要跟我撕。MVC是種思想，跟在前端後端沒多少關係，在不同的環境下，M.V.C.的實現方式可以很不相同。
即使沒有前端MVC，MVVM的出現，前後端分離都是大勢所趨，在大部分情況下，前後端分離的利都是大於弊的。前後端分離後，後端絕大部分時候不再需要輸出HTML代碼，取而代之的是JSON純數據。這個就是後端MVC中的V，已經足夠簡單，幾乎不用寫什麼東西，所以，更多的精力放在MC上了。
而此時的後端的V，卻是前端的MV*中的M。至於如何把M表現為V，由前端決定。
這樣一來，相比之下，前端工作確實繁重了不少，所以前端才這麼缺人啊。輸出html本來就不是web服務端開發人員應該做的工作，服務端開發的工作就是提供增刪改查介面，後台許可權設置之類的工作，前端，包括安卓和ios都只是展示數據，驗證數據。不涉及項目部署的情況下就是如此，現在的很多小公司的開發模式，前端只提供模板，然後讓服務端人員去套的原因僅僅是因為前端工程師太少太貴，現在活躍的前端大牛基本上都是從服務端轉過來的，很多新入行的能力僅僅局限於重構原型圖，無法滿足前後端分離的開發需要。
首先，MVC/MVVM 和前端後端沒有直接關聯。
其次，兩者並存肯定還是要長期存在的~
最後，看看Vue2.0不是有個特性叫SSR么，你看，這再次重申第二點呀 ，考慮的問題和角度不一樣，單純考慮實現當然是前端簡單，但是再考慮網路，SEO，以及可控性等等，後端渲染還是要的~只是另一種展現形式而已，就像你知道了漢堡薯條能也能吃飽但是你大部分時候還是得吃白米飯不是。
MVC只是一個角色劃分。它只規定協作關係而不管具體實現。
所以不管你把複雜度從前端折騰到後端，還是從後端折騰到前端，整個系統該是MV*還是MV*，不會因為你折騰了幾下就少掉多少必要的複雜度。
至於把渲染全部推給前端這種做法的得失，沒有你想的那麼簡單。你可以自己google一下"pros and cons of SPA"。趨勢是這樣沒錯。
但是按你的描述，後端模板退出歷史舞台全是前端的功勞？？我就告訴你，後端服務化也是很重要的，不服務化你們上哪兒抓json去。
我們後端的決定也是很重要的，將來報道上出現偏差，你們前端可是要負責的。
退出還早不是所有前端都需要mvc，另外有些性能優化上後端模板依然有優勢，純前端渲染必然所有數據都要從介面獲取，如果出現時序依賴頁面載入問題會變得顯著，最終首屏優化還是會回到服務端渲染。
一方面必須要讓前端掌握視圖層，這對大家都好。而前端渲染讓這變得順其自然。
另一方面礙於SEO，傳統的網站項目還是要靠後端模版直出。這樣前端就不樂意了，從開發階段到維護階段不停的為了一個頁面撕逼。後來就有了中間層的解決方案，後端只負責數據介面，再用nodejs搞一層用來直出需要SEO的頁面。前端和nodejs比較親近，就合理的掌握了這一層。這樣就需要更多優秀的jser，但顯然很多公司是達不到這一點的，所以後端渲染還是有其存在的必要。如果退出舞台，那之前那些全棧工程師怎麼辦？前後端分離基本上是一線互聯網城市的做法，但不少二三四線城市還是不會前後端分離，因為它們的重點不在於技術，而是在於運營。如果我們去外包公司做的網站上面看，大部分網站都沒有打包，代碼混淆，甚至是依舊套的各種jquery插件。存在必合理。
也不用那麼糾結。在你的工作方式上，用後端的V或者是前端的mvvn都取決於它們帶給你的開發效率怎麼樣，以及誰更能解決你的問題。
題主問的不準確，react這些都帶模板引擎，估計你想問的是後端模板引擎會不會消失.
怎麼可能退出呢，server side render最起碼有兩點是mvvm做不到的吧1. 能極大提升首渲速度2. SEO何況目前三大框架其都支持伺服器渲染（ ng2, react, vue2 ）
這些框架的出現只是為了讓開發者擁有更多的解決方案，用來應對更多不同的場景，並不是為了去取代別人，開發的核心是開發者。
先說結論:
後端模板引擎還遠遠沒有退出歷史大舞台的條件。一
在網站上，即使是mvvm，部分網站頁面的初級介面還是需要後端模板來渲染的，只不過裡面的內容省了。當瀏覽器載入完初級介面的的時候，瀏覽器再請求數據，前端模板引擎再渲染成最終界面。二
依靠前端渲染的網頁搜索引擎的爬蟲們不好抓百度搜狗等都在忙著掙推廣費去了，你個小破站連基本的seo都不好好待侯爬蟲們，凈弄些非主流三
至少目前來看，mvvm更適用app客戶端四
對於團隊分工，傳統的mvc更界限分明後端程序老老實實套前端提供的html就行了，為毛還要開發新的api
前端程序老老實實切他的html就行了，人家為毛要學vue.js等等框架編不下去了…做網站的還是需要模板的，主要是為了容易讓搜索引擎索引到。如果純js的，頁面太乾淨，搜索引擎會將你遺忘。
不過做應用的的確是這樣的，再也不需要類似JSP這樣的模板了。這樣能幹死一堆只會切圖配色的偽前端
瀉藥
事實上都是這麼做的。後端負責介面，不再有view。但是view並不是在客戶端渲染，而是再前端伺服器渲染。
業務架構一般是這樣：
瀏覽器→渲染伺服器→介面伺服器。後端完全不管展示，前端負責渲染伺服器代碼開發。脫離場景談架構都是耍牛氓！
不同的方案會有不同的優劣，我們來比較一下後端模板渲染和前端模板渲染：
一、後端渲染
頁面呈現速度：快，受限於用戶的帶寬 流量消耗：少一點點（可以省去前端框架部分的代碼） 可維護性：差（前後端東西放一起，掐架多年，早就在鬧分手啦）seo友好度：好
編碼效率：低（這個跟不同的團隊不同，可能不對）二、前端渲染
頁面呈現速度：主要受限於帶寬和客戶端機器的好壞（不過這兩個現在越來越好），優化的好，可以逐步動態展開內容，感覺上會更快一點。流量消耗：多一點點（一個前端框架大概100K左右吧）當然，有的用後端渲染的項目前端部分也有在用框架。
可維護性：好，後端純，前端也純
seo友好度：差，雖然google可以爪ajax了，不過國內我度還是…… 編碼效率：高（主要不用反覆和後端掐架了，可以專心寫代碼了）這樣看上去，前端渲染各種先進，這也是為什麼前端框架現在越來越多，而且，人越來越貴，機器越來越便宜，當然是怎麼開發快好維護，怎麼來咯。
所以，後端渲染就要退出歷史舞台了么？當然不是！
你看現在移動互聯網這麼發達了，為什麼我們還需要用簡訊聯繫別人呢？（一角錢一條簡訊好貴啊 摔！）除了大家說的，需要秒開首屏以及對seo有高要求的應用場景，前端渲染還有下面幾個地方，不能完成，只能後端渲染：
- 導出為.doc .docx ，
- 導出為 .xls .xlsx ，
- 導出為pdf ……
- 自定義紙張的列印
- 對傻逼瀏覽器的兼容
- 等
不可能的，MVVM的web app不利於SEO。
推薦閱讀：
※為什麼越來越多的大型網站開始放棄原來自己開發的論壇，開始啟用discuz呢？
※作為一個前端工程師，是往node方面轉，還是往HTML5方面轉？
※如何讓後端開發高質完成前端的工作？
※前端開發現在都在用什麼系統和相應IDE？
※react 中inline-block的間距去哪了？
TAG:前端開發 | 程序員 | JavaScript | MVC | AngularJS |