1樓：
以下只為個人看法：
描述之前先鋪墊幾個概念：
TTFB：首位元組到達時間，是頁面載入效能比較重要指標，對於使用者感知不大，主要針對研發人員，表示網路後端的整體響應時長。
FP：首次螢幕繪製。
FCP：首次內容繪製，對應使用者是有感知的，可算可以看到點東西。
TTI：可互動時間。
從服務端生成html(如servlet)慢慢開始前後端分離，這是前後端研發模式的調整，SPA是這種模式下帶來的產物。
客戶端渲染簡易流程：
1、瀏覽器請求後端
2、後端響應，返回html模版
3、瀏覽器繼續請求載入boudle.js
4、執行React邏輯
5、開始渲染頁面【中間還夾著往後端請求資料的往返】
那麼這種渲染架構的缺點是：
1、隨著應用程式複雜性增加，你的boudle會越來越多(哪怕你做了code split、延遲載入)。bundle越多，會影響到你應用的FCP、TTI時長，這對於使用者體驗是不友好的。
2、SEO。其實有些搜尋引擎已經在"進化"了。
服務端渲染：在服務端完成頁面模板、資料預取、填充，並且在服務端就可以將完整的 HTML 內容返回給瀏覽器。
優點：1、FCP、TTI會縮短，對使用者體驗會更好。
缺點：1、TTFB時間會延長，因為在伺服器需要時間處理業務邏輯。
2、研發成本上公升，因為需要接入BFF。
關於渲染架構的演進、描述。推薦閱讀：
2樓：小強趙
主要是三方面：
1、SEO
2、白屏時間(頁面載入速度)
3、開發效率。
其實現在流行的伺服器端渲染是「伺服器端和客戶端同構渲染」解決方案。
詳細的內容參見我的另乙個回答: https://www.
3樓：大魚
SSR開發體驗、可維護性(包括元件復用性)上的弊端十分明顯，之所以至今還沒消失是因為能解決某些業務模式的痛點：
比如虎撲這種強依賴搜尋引擎流量的(spa + puppeteer預渲染 + 分離爬蟲流量也能實現，但成本不比ssr低)；
還比如對效能有極高要求的落地頁(細微的載入速度差別就能帶來營收上的巨大差異)。
技術本質上是需要服務業務的，不管是它的誕生還是以後的發展反向。
4樓：
效能，手機端渲染複雜頁面慢得致命。
seo，國內引擎對前端渲染不友好，你可以在各個平台（如釘釘，QQ）上分享網頁，前端渲染連標題都取不到。
服務端渲染的效能更好優化: 快取，CDN。
5樓：冰凝
前後端分離環境。
無論是 Vue還是React。
都不推薦也不流行服務端渲染。
服務端渲染是為了SEO而妥協的產物。
現在前端框架的服務端渲染輪子很多，Vue可以很方便很少改動的啟動服務端渲染。
前後端分離相對於傳統的開發是有優點的。
後端前端都可以專注他們的工作。
同時伺服器不再負責頁面生成，節省大量的運算資源以及頻寬資源。
那麼前端啟用服務端渲染後，還能節省運算資源和頻寬資源嗎？
答案是能的，只是相比之前要少一點。
服務端渲染，只渲染第一次頁面的，以後頁面的後續更新則是和之前前後端分離是一樣的邏輯，所以只要不是一次性訪問，那麼依舊要比後端渲染節省運算資源和頻寬。
前後端分離，其實能讓工作流程簡化不少，前端可以在沒有後端的情況下完成頁面架構，後端也可以在沒有前端的情況下完成流程開發和測試。
在開發過程中能規避不少前後端互動帶來的時間浪費，也能讓前後端程式設計師專注於他們的工作。
同時現在前端由於Vue React等流行框架都採用虛擬dom的設計，所以，理論上前端程式是可以替換掉執行時來保持相容的。
就像 Weex Rn 等等。
可以一套程式直出 Web Android iOS 和各種小程式。
何樂而不為呢
6樓：
目前還是前後端分離是主流啊...
不過技術變化都很快，現在大量的專案都是分布式架構的，大量使用雲或實體伺服器，不知道這樣持續下去，會不會又出現部分頁面在服務端渲染，真不一定！
7樓：軟考真題 開發者
spa絕對不只是因為「把一些渲染計算的步驟拋向前端來減輕服務端的壓力」。
計算力對於伺服器資源來說很重要，但是絕對不是架構人員首先考慮的問題！
事實上，run every 是每乙個技術人員的追求。
目前形勢下，這是個烏托邦。
但是可以把介面抽離出來「run every"。
介面不再針對android ios web 小程式等等環境開發。
把具有差異性的表示層分離出去，介面單獨一層。世界就美好起來了。
當然會有很多問題，比如SEO，社群有解決方案。
困難有，但是能難住凌晨4點的程式設計師嗎？
8樓：
最近出來了http2.0，核心功能是提高請求的併發性。相信以後會是前端渲染的趨勢。畢竟，前端渲染靈活多變。當然，拋開場景談技術，都是耍流氓
9樓：在路上
技術玩法一直沒變，一直是只存在c/s模式。b/s模式是個偽命題，瀏覽器不是c端嗎，瀏覽器自帶html解析而已，最後都是c端渲染，顯示卡渲染，什麼？s端有渲染概念？
最多是模版解析成html文字，瀏覽器http去獲取它而已。現在開發人員基礎知識缺乏嚴重啊。
10樓：
不要搞極端，正常情況下是服務端渲染和客戶端渲染並存的缺一不可
任何不需要使用者操作就顯示的資訊，都應該由服務端渲染只有由使用者操作才會產生結果的和隨時間動態生成資訊的應該由客戶端渲染而且客戶端渲染應該基於服務端渲染的結果
前後端分離不應該分在硬體上
應該是任何渲染相關都是前端
11樓：秋天與蟬
服務端渲染最大的乙個好處就是SEO，不過題主所說的過去的服務端渲染和現在的服務端渲染，有點不一樣。題主所指的過去的「服務端渲染」，是直接輸出html等文件，而現在的後端進出的都只是資料，不需要去關注其他。而前端考慮的也只是使用資料。
這樣的好處首先一點就是開發效率，前後端可以同步進行，維護起來也很方便，另外就是能減少介面的暴露。樓上有一位貌似把NodeJS貶的一文不值，這個觀點我是很不贊同的。歷史總是在進步，我們所做的，不過是順應技術的發展所帶來的改變。
我們是前端，我們不搞事情。
12樓：FeRookie
流量很重要嗎？自己開心就好唄，好吧，純屬扯淡！只能說搜尋引擎不給力啊[wuliblog](http://www.
55lover.com)
13樓：by wang
1 seo，沒啥好說的了。
2 首屏響應速度， 前端渲染即便分塊載入速度也不甚理想。
3 路由。這個我只知道react-router，如果想要直接訪問指定路由，是需要做後端渲染的。
4 把整個表現層交給前端開發來處理會比較方便。
14樓：圓胖腫
前後端分離對於後端不想寫web ui的程式設計師來說是好事但是伺服器端渲染也有它的好處，乙個最明顯的好處就是不用做seo這個其實在vert.x上可以很容易做到
因為vertx-web支援一大堆html templates我們讓美工直接把介面做好之後，直接一套，就可以用了
15樓：
補充一下關於分離的觀點：
// 恩
((topView
)=>)('因為人分離才分離')
16樓：吳維偉
我認為前端的發展主要在兩個方面。
乙個是開發效率，以更快的速度實現業務需求；
乙個是頁面效能，比如首屏時間等。
開發效率是大家首要考慮的事情。所以你可以看到，乙個新的技術方案的出現可以極大的提高開發效率，但往往會損失一部分效能。之後大家再考慮怎麼把弄丟的效能找回來。
之前推薦vue，react做前端渲染，是因為開發快啊。但開啟頁面時白屏時間也是肉眼可見的增長了。現在完善了這麼乙個方案，可以在不太影響開發效率的情況下，把效能補回來，當然要推薦大家用起來。
17樓：糞鬥
軟體工程架構的發展離不開硬體的進步。前端和後端的分工不過是對既有硬體水平的適應。在整個網路中，前端，網路，後端的能力都是架構設計需要考慮的著眼點。
把前端的渲染放到後端也是對當前硬體環境的適應而已。
18樓：寶丁
在某些場景下，前後端的分離可以帶來一定的開發耦合度的降低，但是有時候服務端渲染html的方法會在一些場景下帶來更大的益處，比如，seo和csrf。
19樓：陸沉
「前後端分離」真不是前端提出來搞事情的。
C / S 架構就是天然 「前後端分離」，服務端你渲染個 QQ 出來給我看看？
到了 B / S ，一開始事情比較簡單，邏輯都堆到 S 上，html 即是 C，html 純用來展示，很少有互動。
後來 Ajax 提出來，B 類的 C / S 的產品慢慢過度到 B / S 架構上，大家發現要原來 html 除了做純展示，還有其他的事情要做。的在瀏覽器上處理的事情越來越多，瀏覽器端的邏輯開始複雜起來。一開始用 jQuery 之類的做簡單 Ajax 區域性更新，後來事情越來越複雜，這時候前端 MVC 、MV* 才開始出現。
具體徐叔的這個回答答得非常好了。
Web 前後端分離的意義大嗎？
回正題。
React 和 Vue 的 SSR（ 服務端渲染 ） 並不是又繞回來了，而是 React 和 Vue 面臨 SEO 的問題時不得不提供的解決方案
如果專案是偏展示類的，真沒必要強上 React / Vue 啥的。
如果專案是偏管理類的，SSR 不 SSR 真的沒什麼關係。
參考：Web 前後端分離的意義大嗎？
Web 研發模式演變 · Issue #184 · lifesinger/blog
精讀前後端渲染之爭
20樓：蔣正
孱弱的爬蟲無法滿足日益發展的前端進化速度。
對 CSR(Client Side Rendering) 做 SEO 的工作為何落在了開發者身上？
21樓：張正誠
因為前端們被鄙視了這麼多年，終於醒過味兒來：不先吃得苦中苦從後端不願意做的髒活累活幹起，怎麼能從鄙視鏈底層爬起來和其他程式設計師平起平坐談笑風生？
22樓：undefined
在實際業務中兩點隱藏的硬性需求一直被現在的技術控忽略，seo友好和使用者體驗友好，說人話就是，搜尋引擎更簡單的收錄和減少白屏時間。
現在主流搜尋引擎其實已經對簡單的客戶端js輸出的結果收錄。但更直接的方式還是依賴於伺服器直接響應的具體內容。
其次，在面對越來越挑剔的使用者群體的時候，最快的把主要內容給使用者成為產品不折不扣的剛需。
其實主體思想並沒有發生任何變化，只是技術控是不是被裡流行這個詞給綁架了自己的認知
為什麼要做node js服務端渲染？
我是老尚 這其實是乙個工作場景不斷 前移 的過程。最早期的頁面只是html css，後來內容都是直接套在php jsp裡的。但這樣速度很慢，並且在架構上存在緊耦合。後來把頁面的渲染生成放在js裡，前端只要獲得Json資料，就可以動態的更新頁面，這就是ajax。這時前端頁面的更新 響應速度有了極快的提...
c 遊戲服務端程式設計有什麼書籍推薦嗎？
青玉白露 這裡推薦兩本，一本是Linux高效能伺服器程式設計另一本是Unix網路程式設計。看完這兩本書就可以考慮自己寫乙個web伺服器了，下面是乙個教程，可以學習一下 青玉白露 TinyWebServer 從0到伺服器開發！做了上面的這個專案之後，回答一些面試題 青玉白露 Tinywebserver...
react js在伺服器端渲染有什麼好處？渲染是怎麼個流程？
body no 剛做的服務端渲染開源專案 可以看下這個 GitHub bodyno universal react starter kit 服務端渲染的React手腳架。完美使用 React,Redux,and React Router！最好用的腳手架 不知道 純粹用React做伺服器端渲染 As ...