貌似幾年之前從服務(wù)端生成html(如servlet)慢慢開始前后端分離，把一些渲染計(jì)算的步驟拋向前端來減輕服務(wù)端的壓力。但是為啥現(xiàn)在又開始流行在服務(wù)端渲染html了呢？如vue全家桶或者react全家桶，都是推薦通過服務(wù)端渲染來實(shí)現(xiàn)路由的。單純的是因?yàn)閂irtual DOM的強(qiáng)大還是別的什么原因？

1.方應(yīng)杭

這要從大概八年前說起，事情是這樣的

1 一開始，html 就是后端渲染的。不過后端發(fā)現(xiàn)頁面中的 js 好麻煩（雖然簡單，但是坑多），于是讓公司招聘專門寫 js 的人，也就是前端

2 前端名義上是程序員，實(shí)際上就是在切圖（CSS）和做特效(JS)，所以所有程序員中前端工資最低，職位也最低。所以前后端的鄙視鏈就出現(xiàn)了。

3 nodejs 和前端 mvc 的興起讓前端變得復(fù)雜起來，前端發(fā)現(xiàn)翻身的機(jī)會(huì)，于是全力支持這兩種技術(shù)，造成本不該做成 spa 的網(wǎng)站也成了 spa。慢慢地前后端分離運(yùn)動(dòng)從大公司開始興起，目的就是前端脫離后端的指指點(diǎn)點(diǎn)，獨(dú)立發(fā)展。（表面上是為了「代碼分離」，實(shí)際上是為了「人員分離」，也就是「前后端分家」，前端不再附屬于后端團(tuán)隊(duì)）

4 spa 之后發(fā)現(xiàn) seo 問題很大，而且首屏渲染速度賊慢，但是自己選的路再難走也要走下去，于是用 nodejs 在服務(wù)端渲染這一條路被看成是一條出路

5 其實(shí)這是第二個(gè)翻身的機(jī)會(huì)，如果 nodejs 服務(wù)器渲染成為主流，其實(shí)就相當(dāng)于前端把后端的大部分工作給搶了，工資壓過普通后端指日可待

6 然而結(jié)果是 nodejs 服務(wù)端渲染始終是小眾，因?yàn)楹蠖艘矝]那么脆弱，java php rails 十多年沉淀的技術(shù)豈是你說推翻就推翻的，已經(jīng)運(yùn)行多年的項(xiàng)目又豈是容你隨便用 nodejs 重寫的，另一方面 golang 等技術(shù)的興起也給 nodejs 不少壓力。最終只有少部分前端特別強(qiáng)勢(shì)的團(tuán)隊(duì)成功用上了 Node.js 做渲染（比如阿里的一些團(tuán)隊(duì)），大部分公司依然是用 PHP 渲染 HTML。

7 于是 nodejs 退一步說好好好我不搶你們的工作，我只做中間層（大部分工作就是渲染頁面和調(diào)用后臺(tái)接口），絕不越雷池。后端說算你識(shí)相。現(xiàn)在 nodejs 主要搞什么微服務(wù)，也是為了搶后端還沒注意的市場(chǎng)。

你要看一門技術(shù)的發(fā)展主要應(yīng)該看背后的人是誰，應(yīng)用場(chǎng)景是哪些，最后才是技術(shù)細(xì)節(jié)。

nodejs 的火在中國早就燒過了，以后估計(jì)不會(huì)大火了，作為前端了解一下還是不錯(cuò)的，但是如果你是后端的話，看不看都無所謂，nodejs 跟其他后端開發(fā)框架差異并不大，單線程異步既是優(yōu)點(diǎn)也是缺點(diǎn)，你就把它當(dāng)做一種范式研究就好。

我是一個(gè)堅(jiān)定的『前后端分家』反對(duì)者，前后代碼可以分離，但是人員絕對(duì)不應(yīng)該分離。前后端撕逼的事情在大公司天天都在發(fā)生，全都是因?yàn)榍昂笫莾蓚€(gè)團(tuán)隊(duì)，利益不同。實(shí)際上前端推 nodejs 渲染就是在試圖重新讓前后端合成一體。

但是前端不能明說這件事，因?yàn)槿绻亚昂蠖瞬块T合并，拆掉的肯定是前端部門。

合，則相當(dāng)于自斷前程。

不合，則永遠(yuǎn)沒法解決seo和首屏加載慢的問題。

所以前端真的挺矛盾的。

JS 也有一個(gè)矛盾的地方，凡是瀏覽器上的框架（Vue React）都說自己能適應(yīng)「復(fù)雜」場(chǎng)景，凡是 Node.js 上的框架（express fastify koa）都說自己是「輕量級(jí)」框架。

為啥？因?yàn)闉g覽器是 JS 的主戰(zhàn)場(chǎng)，而且無敵手。而服務(wù)器上，JS 的經(jīng)驗(yàn)積累還是太少了，搞企業(yè)級(jí)服務(wù)，Node.js 是敵不過 Java、PHP 的，沒辦法，發(fā)展得太晚了。所以目前只能搞「輕量級(jí)」咯。egg.js 號(hào)稱是企業(yè)級(jí) Node.js 框架，用過的人來評(píng)我就不評(píng)了。

有些大佬提出「大前端」的概念，意思是前端也要會(huì)后端，但是我們心還是前端的。

這不就是把以前的『前后端一個(gè)人做』換了個(gè)說法嘛。

反正你現(xiàn)在讓后端去學(xué)前端，后端肯定是不愿意躺這渾水的。只能前端自己想辦法咯。

想來想去就只有 Node.js 中間層做 HTML 渲染了。

當(dāng)初是你要分開，分開就分開。

現(xiàn)在又要用kpi，把我喚回來。

但是后端kpi跟你前端kpi是不同的呀，所以沒戲。

這些話也就我這種不在大廠的人敢說，在大廠的人根本不敢說，畢竟跟后端低頭不見抬頭見的。

最后告訴你一個(gè)小秘密。由于阿里 nodejs 用得還算多，卻招不到人，所以從功利的角度出發(fā)，也許你學(xué) nodejs 比學(xué) java 更容易進(jìn)阿里，畢竟阿里的 java 大神多如云，nodejs 大神卻不多。

你說是吧。

但是從另外一個(gè)角度考慮，SEO 不友好的頁面我是支持的。

如果你的頁面是對(duì) SEO 不友好的，那么百度的重要性就會(huì)被削弱。現(xiàn)在是移動(dòng)互聯(lián)網(wǎng)時(shí)代，大家在手機(jī)上幾乎不用百度，都是直接點(diǎn) App 點(diǎn)微信公眾號(hào)的，SEO 不友好問題不大。首屏速度隨著 5G 網(wǎng)絡(luò)的普及也不會(huì)是問題了。

只要能讓百度利益受損，我覺得 SPA 這事還是值得做的。服務(wù)端渲染還是直接免了吧，大家都不做 SEO 讓百度倒閉就最好咯~（只是我的幻想而已，不要當(dāng)真，我是百度的腦殘黑，黑百度從來不需要理由）

感謝你看我說了這么多，不過說到最后，我也沒給出啥結(jié)論，只是把我觀察到的告訴你了。

你要不要學(xué)、要不要用服務(wù)器渲染HTML，都是需要你自己思考的事情。

還是那句話，我不喜歡說中庸的觀點(diǎn)，我喜歡跟你說一個(gè)極端的觀點(diǎn)，然后會(huì)有人用另一個(gè)極端的觀點(diǎn)反駁我，他說服不了我，我也說服不了他，但是最終，你會(huì)得出自己的觀點(diǎn)。

2.張強(qiáng)張耳朵

SSR的好處無非就2點(diǎn)

首屏渲染

SEO

然而這2點(diǎn)從來都很重要，可為啥之前有段時(shí)間不流行SSR呢？

往早了說，因?yàn)镴S慢，網(wǎng)絡(luò)慢，客戶端本身也很慢，所以為了讓功能可用且保證基本的流暢，前端就純展示好了，交互非常少，渲染的活就交給server吧，因?yàn)楫?dāng)時(shí)前端很薄，所以很多前端的活都是后端兼的（那時(shí)候好像不怎么區(qū)分前后端，大家都是web開發(fā)工程師，按現(xiàn)在的說法叫全棧工程師）。

再后來，js快了，網(wǎng)絡(luò)快了，客戶端本身性能也高了，所以我們可以往客戶端堆各種復(fù)雜的功能邏輯和交互，需求和工作量double后你讓一個(gè)web開發(fā)工程師干2個(gè)人的活感覺身體要被掏空，所以一部分人選擇了js專精，成為了專職前端。

對(duì)于前端，特別是互聯(lián)網(wǎng)公司的前端來說，那UI的變更迭代的頻率不知道要比業(yè)務(wù)邏輯本身高到哪里去了，產(chǎn)品動(dòng)不動(dòng)就要改UI改交互，這時(shí)候本身疲于需求變更的前端還要去求后端哥哥幫你上線新html模板，后端哥哥本身并不關(guān)心你html的dom怎么編排，還得每次都要人肉配合你改，真是苦不堪言+一臉嫌棄。

剛好這個(gè)時(shí)候智能手機(jī)火了，SEO感覺并不怎么重要，3G網(wǎng)絡(luò)好像也還行，除了首次加載慢之外其他時(shí)間的渲染體驗(yàn)慢的并不明顯，那么好了，還要啥SSR，大家都CSR好了，對(duì)于本身工作超飽和還找不到人的前端來說能按時(shí)寫完功能，后端哥哥按約定完整交付接口不扯皮就已經(jīng)不錯(cuò)了。任何應(yīng)用都是最先保證功能的上線，優(yōu)化什么的都是后話。從此，前后端開始分離。

再往后node有了，理論上來說，可以做到SSR和CSR都由前端維護(hù)，但對(duì)于歷史悠久底子薄的JS生態(tài)圈來說，同構(gòu)技術(shù)依然還是匱乏的，CSR和SSR分別維護(hù)兩套代碼怎么想都很惡心，干脆就還是繼續(xù)CSR好了，直到以REACT為代表的渲染庫出現(xiàn)，才使得前端步入同構(gòu)時(shí)代，這時(shí)候SSR的成本比以前低了一倍，自然前端們又要開始躍躍欲試提出了新的KPI指標(biāo)。也就是為什么現(xiàn)在又開始流行服務(wù)端渲染的原因。

其實(shí)整個(gè)歷史的進(jìn)程可以總結(jié)為以下脈絡(luò)：

硬件/帶寬/JS引擎的提速–>前端邏輯變的復(fù)雜–>前后端分工–>前后端分離–>html姓”前”–>如何渲染html要跟隨前端技術(shù)棧的發(fā)展節(jié)拍–>等待前端相關(guān)技術(shù)成熟–>又流行SSR

3.nekocode

「又流行」感覺像是開歷史的倒車，但其實(shí)并不是。以前是 Back-end（或者說 Full-stack）工程師負(fù)責(zé) SSR，但是現(xiàn)在是 Front-end 工程師負(fù)責(zé) SSR 了啊。在目前這個(gè)知識(shí)爆炸的年代，前后端的職能目前已經(jīng)被分割得很開，大家都不愿意去淌對(duì)方那攤混水，而 Rendering 這事從語義上出發(fā)就屬于 Front-end 的范疇，讓 Back-end 去做這事，其實(shí)很多人是不愿意的。

回到問題本身，SSR 的「又流行」其實(shí)是 Front-end 社區(qū)工具棧不斷進(jìn)化的體現(xiàn)，也是歷史的必然啊。幾年前，SPA/CSR 概念的大熱，讓很多 Front-end 把他們當(dāng)做萬金油了。其實(shí)大家都知道 CSR 有著 SEO 的問題，而且頁面渲染速度肯定比不上 SSR，但苦于社區(qū)中沒有解決這個(gè)問題的工具棧，所以大家都對(duì)這個(gè)問題視而不見了。

而隨著 Front-end 社區(qū)造輪子大潮的興起，出現(xiàn)了一個(gè)很關(guān)鍵的歷史轉(zhuǎn)折點(diǎn) —— Node.js 的出現(xiàn)。Node.js 賦予了 Front-end 在服務(wù)端執(zhí)行 Js 的能力，有了這個(gè)環(huán)境和土壤，F(xiàn)ront-end 工程師們終于可以考慮如何用 Js 來實(shí)現(xiàn) SSR 了，于是 React 和 Vue 等主流框架后面開始支持 SSR 也就成了必然。

所以之前并不是不流行，而是因?yàn)榍昂蠖寺毮艿姆蛛x，Back-end 不愿意做這事了，F(xiàn)ront-end 沒有條件去做。現(xiàn)在有條件了，自然又開始流行了。

---------------------

作者：代碼灣

來源：CSDN

原文：https://blog.csdn.net/b9q8e64lo6mm/article/details/79418969

版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！