我們先來截個圖看一下
第一個是后端渲染，第二個和第三個是前端渲染。
nuxt是后端渲染，通俗來說：優點：首屏加載快 seo友好，壞處是更吃服務器資源，並發會受到影響。舉例來說：原本並發3000 后端渲染估計會降到200。
以上是個人通俗解釋，下面是從網上找來的解釋，希望大家可以了解更清晰。
后端渲染（SSR、服務端渲染）
后端渲染HTML的情況下，瀏覽器會直接接收到經過服務器計算之后的呈現給用戶的最終的HTML字符串，這里的計算就是服務器經過解析存放在服務器端的模板文件來完成的，在這種情況下，瀏覽器只進行了HTML的解析，以及通過操作系統提供的操縱顯示器顯示內容的系統調用在顯示器上把HTML所代表的圖像顯示給用戶。
前端渲染（SPA、單頁面應用）
前端渲染就是指瀏覽器會從后端得到一些信息，這些信息或許是適用於題主所說的angularjs的模板文件，亦或是JSON等各種數據交換格式所包裝的數據，甚至是直接的合法的HTML字符串。這些形式都不重要，重要的是，將這些信息組織排列形成最終可讀的HTML字符串是由瀏覽器來完成的，在形成了HTML字符串之后，再進行顯示。
題主所提到的幾個技術，我認為模板這個詞語並不能用來區分這些技術的本質，模板只是一種提供給程序來解析的一種語法，換句話說，模板是用於從數據（變量）到實際的視覺表現（HTML代碼）這項工作的一種實現手段，而這種手段不論在前端還是后端都有應用。
以下為本人自己的想法：在性能上，我認為后端渲染最終會被前端渲染，因為后端渲染將所有的HTML生成集中在了一個服務器上，而前端渲染將這部分工作分發到各個終端上。另外，對於開發而言，這樣能夠避免后端開發人員過多的編寫HTML代碼，后端開發人員只需和前端開發事先商定好數據格式，后端就只需將數據生成，用數據交換格式包裝，再發送出去就可以了，這樣能夠使開發人員之間的分工更加明確。
再附上稀土掘金上的一段理解：
SEO
很重要，所以要普及。
SEO： 搜索引擎優化（Search Engine Optimization），它是指通過站內優化，如：網站結構調整、網站內容建設、網站代碼優化以及站外優化等方法，來進行搜索引擎優化。
簡單說： 通過各種技術（手段）來確保，你的Web內容被搜素引擎最大化收錄，最大化提高權重，帶來更多流量。
常見關鍵詞：白帽、黑帽、SEM、Backlink、Linkbait、PageRank、Keyword Stuffing...，總之都圍繞着一個核心：SEO；流量是變現的快車道，SEO是低成本獲取流量的最佳方法。
SPA
SPA：單頁Web應用（single page web application，SPA），就是只有一張Web頁面的應用，是加載單個HTML 頁面並在用戶與應用程序交互時動態更新該頁面的Web應用程序。
簡單說： Web不再是一張張頁面，而是一個整體的應用，一個由路由系統、數據系統、頁面（組件）系統...組成的應用程序，其中路由系統是非必須的。
大部分的Vue項目，本質是SPA應用，Angular.js、Angular、Vue、React...還有最早的"Pjax"均如此。
SPA時代，主要是在Web端使用了history或hash（主要是為了低版本瀏覽器的兼容）API，在首次請求經服務端路由輸出整個應用程序后，接下來的路由都由前端掌控了，前端通過路由作為中心樞紐控制一系列頁面（組件）的渲染加載和數據交互。
而上面所述的各類框架則是將以：路由、數據、視圖為基本結構進行的規范化的封裝。
最早的SPA應用，由Gmail、Google Docs、Twitter等大廠產品實踐布道，廣泛用於對SEO要求不高的場景中。
SSR
SSR： 服務端渲染（Server Side Render），即：網頁是通過服務端渲染生成后輸出給客戶端。
在SPA之前的時代，我們的Web架構大都是SSR，如：Wordpress（PHP）、JSP技術、JavaWeb...或者DEDECMS、Discuz!等這些程序都是傳統典型的SSR架構，
即：服務端取出數據和模板組合生成html輸出給前端，前端發生請求時，重新向服務端請求html資源，路由也由服務端來控制。
其次，有個概念叫預渲染（Prerendering）。
如果你只是用服務端渲染來改善一個少數的營銷頁面（如 首頁，關於，聯系 等等）的SEO，那你可以用預渲染來實現。
預渲染不像服務器渲染那樣即時編譯HTML，它只在構建時為了特定的路由生成特定的幾個靜態頁面，等於我們可以通過webpack插件將一些特定頁面組件build時就編譯為html文件，直接以靜態資源的形式輸出給搜索引擎。
但實際的商業應用中，大部分時候我們需要的是即時渲染，這也是我們今天討論的主題。
Why
為什么要SSR，為了體驗，還有SEO。
首先，用戶可能在網絡比較慢的情況下從遠處訪問網站 - 或者通過比較差的帶寬。 這些情況下，盡量減少頁面請求數量，來保證用戶盡快看到基本的內容。
可以用Webpack的代碼拆分避免強制用戶下載整個單頁面應用，但是，這樣也遠沒有下載個單獨的預先渲染過的HTML文件性能高。
對於世界上的一些地區人，可能只能用1998年產的電腦訪問互聯網的方式使用計算機。
而Vue只能運行在IE9以上的瀏覽器，你可能也想為那些老式瀏覽器提供基礎內容 - 或者是在命令行中使用 Lynx的時髦的黑客。
在大部分的商業應用中，我們有SEO的需求，我們需要搜索引擎更多地抓取到我們的內容，更詳細地認識到我們的網頁結構，而不是僅對首頁或特定靜態頁進行索引，這是SSR最重要的意義。
且，我們還需要在SSR的基礎上實現SPA，即：首屏渲染。
基本流程是：
在瀏覽器第一次訪問某個URI資源的時候（首屏），Web服務器根據路由拿到對應數據渲染並輸出，且輸出的數據中包含兩部分：
- 路由頁對應的頁面及已渲染好的數據
- 完整的SPA程序代碼
在客戶端首屏渲染完成之后，此時我們看到的其實已經是一個和之前的SPA相差無幾的應用程序了，接下來我們進行的任何操作都只是客戶端的應用進行交互，
頁面/組件由Web端渲染，路由也由瀏覽器控制，用戶只需要和當前瀏覽器內的應用打交道就可以了。
之前在各大SPA框架還未正式官方支持SSR時，有一些第三方的解決方案，如：prerender.io，
它們做的事情就是建立HTTP一個中間層，在判斷到訪問來源是蜘蛛時，輸出已緩存好的html數據，此數據若不存在，則調用第三方服務對html進行緩存，往復進行。
另一方法是自行構建蜘蛛渲染邏輯，當識別UA為搜索引擎時，拿服務端已准備好的模板和數據進行渲染輸出html數據，反之，則輸出SPA應用代碼；
我當時也考慮過此方法，但有很多弊端，如：
需要針對蜘蛛編寫一套獨立的渲染模板，因為大部分情況下SPA的代碼是沒法直接在服務端使用的
搜索引擎若檢測到蜘蛛抓取數據和真實訪問數據不一致，會做降權懲罰，也就意味着渲染模板還必須和SPA預期輸出一模一樣
所以，最好的方法是SPA能和服務端使用同一套模板，且使用同一個服務端邏輯分支，再簡單說：最好Vue、Ng2...能直接在服務端跑起來。
於是，陸續誕生了基於React的Next.js、基於Vue的Nuxt.js、Ng2誕生之日便支持。
沒錯，Nuxt.js就是今天的主角。