前後端分離，是各自蓬勃發展，繁榮的表現。後端有自己的業務邏輯要處理，前端也有各自的呈現要處理，前端提供模板，後端負責渲染，你幹你的，我幹我的，分工明確。後端有成熟的MVC模式和架構，前端出於配合的地位。當時的網站主要以官網+後臺管理的形式存在，多以後端為重，因為後端有大量的業務邏輯需要處理，所以在MVC架構下，有的前端也需要掌握一門後端語言，讓前端接手處理渲染。其實，這時候的前後端配合不像一開始那麼"親密"，開始"打架"，前端說這裡需要後端處理，後端說這裡前端也可以處理，因為二者有相互滲透之嫌。比如，後端處理前端提供的靜態頁面模板，勢必需要對其做一些瞭解，如果前端處理渲染，勢必也要對後端是如何提供數據要有一定了解。程序猿本身作為一種物種，為了進化的需要，技多不壓身，想必也會有所涉獵。於是乎，前後端就在這種撕逼與配合中各自前行。
"Duang，Duang，Duang"，NodeJS重磅來襲，其實JS運行在後端很早就有了，只是沒有NodeJS徹底，來得那麼及時。為了應對前後端的撕逼，有一些公司其實之前就嘗試過將PHP的模板渲染也納入前端，後端只處理業務邏輯，提供數據。這樣在前端和後端，出來了一箇中間層由PHP來完成，以為添加了這道磨合劑就相安無事了。卻發現提高了人工成本的同時，不過是把撕逼提到了另一個層面。隨著NodeJS的完善，相關NPM模塊日趨增多，為何不讓Node接手PHP那一層呢？於是Node解脫了PHP的尷尬境地，又迴歸到它的本質。
一般業務複雜，大公司都會採取類似分離解藕的策略，前後端這種模糊的存在也還有其用武之地。
前後端分離之後，前後端得到相同的重視，前端有了更多的思考空間，也為了應對人們日益增長的個性化需求，同時前端相關技術也落地生根。前端開始有了獨立的架構設計。隨著移動端的新起，前端交互開始變得尤為重要，為了更好的交互體驗，單頁面客戶端渲染開始流行，多頁面服務器端渲染一個很重要的原因就是網絡延時嚴重影響用戶體驗。隨著用戶訪問量的激增，客戶端渲染可以緩解服務器端的壓力。
題主所說的又開始後端渲染，其實跟最原始的後端渲染還是有區別的，更多的是引入Node這樣的中間層渲染。
至於很多人說的是因為SEO的緣故需要後端渲染，也是有的，其實當移動端新起的時候，SEO的因素已經顯得不那麼重要。主要的還是隨著技術的發展，業務的沉澱，系統化的思維本身就是"分離-合併"的過程。還有就是現在網絡帶寬，服務器集群等基礎設施的完善，也會對相應的架構設計有一定的影響。
以上是根據自己親身經歷與實踐，在手機上一個字一個字敲擊而成，或有失偏頗，還望諒解，可留言評論交流。
一筆君
題主有點搞錯了,現在的服務端渲染跟以前的服務端渲染是完全不一樣的.
首先介紹一下以前的傳統模式:服務端渲染,代表是PHP這類,那時候前端只是寫網頁的,偶爾寫點ajax,但是不多,大部分靠服務器查找數據然後渲染出來頁面發送給瀏覽器展示,每次跳轉都要從新執行一遍這個邏輯.因此挺消耗服務端的資源的.
後來H5出來後才有所改觀,單頁應用也逐漸興起,Nodejs使前端可以脫離瀏覽器,進軍服務器寫後端代碼.
非常多的人按捺不住內心的激動,終於不被人稱為"切圖仔"了,而且前端人群非常的多,此時我寫這個回答的時候,NPM上的包就已經有654,218個了!
移動端開始興起,網站的加載速度也開始變得重要,各個網站也開始考慮用戶的感受,如果能降低用戶的流量成本,就能使用戶更快的進入頁面,停留的時間也就更久,更能為公司帶來經濟效益,因此這變得越來越重要.
如果還是以前的傳統方式,每次跳轉都要重新加載頁面下載數據,那麼用戶肯定受不了等待從而離開,損失是非常嚴重的,因此這時候的人瞄準了H5,使用H5構建的單頁應用開始越來越多,只需要加載一次網頁,後面就不需要再次下載,而且還可以做緩存,減少用戶的流量費用.
但是前端很快發現了一個嚴重的問題,爬蟲是不認js的,也就是說你無法給自己的網站做SEO.
SEO 搜索引擎優化是一種利用搜索引擎的搜索規則來提高目前網站在有關搜索引擎內的自然排名的方式.當百度或者其他搜索引擎的爬蟲來到你的網站的時候,它發現這裡面什麼東西都沒有,就只有一些css和js資源連接,但是它並不執行你的js,因此是無法獲取到你的網站信息的,它就無法記錄你的網站信息,用戶使用搜索引擎的時候也就無法查詢到關於你網站的數據信息,這是很嚴重的問題,你的網站流量會斷崖式下跌.
因此針對這個問題,前端想到了一個預處理方案:服務器端渲染(SSR).
前端使用Nodejs搭建服務器,然後在用戶訪問的時候預先執行一些頁面中js的邏輯,渲染成HTML,將它們直接發送到瀏覽器,很多流行的開源前端框架已經集成了這類方式,比如Vue.js,React.js,Angular.js等等.
與傳統 SPA（Single-Page Application - 單頁應用程序）相比，服務器端渲染(SSR)的優勢主要在於：
1.更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。如果 SEO 對你的站點至關重要，而你的頁面又是異步獲取內容，則你可能需要服務器端渲染(SSR)解決此問題。
2.更快的內容到達時間，特別是對於緩慢的網絡情況或運行緩慢的設備.無需等待所有的 JavaScript 都完成下載並執行,才顯示服務器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面.通常可以產生更好的用戶體驗,並且對於那些時間就是金錢的應用程序而言,服務器端渲染(SSR)至關重要。
使用服務器端渲染(SSR)時還需要有一些權衡之處:
1.涉及構建設置和部署的更多要求.與可以部署在任何靜態文件服務器上的完全靜態單頁面應用程序(SPA)不同,服務器渲染應用程序,需要處於 Node.js server 運行環境.
2.在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源,因此如果你預料在高流量環境下使用,請準備相應的服務器負載,並明智地採用緩存策略.
在對你的應用程序使用服務器端渲染(SSR)之前,你應該問第一個問題是否真的需要它.這主要取決於內容到達時間對應用程序的重要程度.例如，如果你正在寫一個活動頁,那麼初始加載時的額外幾百毫秒並不重要,這種情況下去使用服務器端渲染(SSR)肯定是一個小題大作之舉.然而,內容到達時間(time-to-content)要求是絕對關鍵的指標，在這種情況下，服務器端渲染(SSR)可以幫助你實現最佳的初始加載性能.
愛生活的森波
那些只會搞前端js的看到nodejs也能玩服務端了，還不高潮了麼，還不趕緊把java php c#造過的輪子又造一遍麼，說白了就是浪費地球資源
aefee
這個問題的起點可以歸結為大前端的崛起而興起來的，其實也是有一定的需求場景導致的。
純粹的前端渲染僅僅只是在原始狀態下，我們使用新興起來的mvvm設計模式框架來打造的站點結構，所有的編譯，渲染時間幾乎都是由瀏覽器來承擔，所以相當於把很多的性能負擔均攤給了用戶，其實對於碼農來說，這其實是一個比較好的方案。
但是由於前端的熱門，大家在越來越多的應用，系統都漸漸使用前後端隔離，這種技術越來越多的使用起來。
那麼擺在用戶面前最直接的就是首屏，響應時間的感知，碼農需要去解決不同瀏覽器上的渲染異常並且儘量讓其更快，這個時候後端渲染就順勢而生了，它解決了這些比較頭疼的問題，也更好的兼容了SEO。
不過現在各類前端框架都提供了自己的ssr支持，也有不少優秀的腳手架幫助大家一健部署ssr環境，所以按照應用需求的話適當轉變業務為SSR也是不錯的選擇。
孽肱仔
題主這個問題真是有點，額。
什麼是服務端渲染？以前的php、jsp、.net做web難道不都是服務端渲染好html再通過web server發送前端嗎？
你說的服務端渲染難道是指由大前端而興起的spa之類的嗎？那也只是對seo有需求的才要通過服務端渲染好再發送給前端，沒有seo需求的完全無所謂什麼服務端渲染了。
我的煎蛋去哪了
榮榮榮榮
ge'r'ge'r
