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

1.方應(yīng)杭

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

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

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

3 nodejs 和前端 mvc 的興起讓前端變得復(fù)雜起來(lái)，前端發(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 問(wèn)題很大，而且首屏渲染速度賊慢，但是自己選的路再難走也要走下去，于是用 nodejs 在服務(wù)端渲染這一條路被看成是一條出路

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

6 然而結(jié)果是 nodejs 服務(wù)端渲染始終是小眾，因?yàn)楹蠖艘矝]那么脆弱，java php rails 十多年沉淀的技術(shù)豈是你說(shuō)推翻就推翻的，已經(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 退一步說(shuō)好好好我不搶你們的工作，我只做中間層（大部分工作就是渲染頁(yè)面和調(diào)用后臺(tái)接口），絕不越雷池。后端說(shuō)算你識(shí)相?，F(xiàn)在 nodejs 主要搞什么微服務(wù)，也是為了搶后端還沒注意的市場(chǎng)。

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

nodejs 的火在中國(guó)早就燒過(guò)了，以后估計(jì)不會(huì)大火了，作為前端了解一下還是不錯(cuò)的，但是如果你是后端的話，看不看都無(wú)所謂，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 渲染就是在試圖重新讓前后端合成一體。

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

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

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

所以前端真的挺矛盾的。

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

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

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

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

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

想來(lái)想去就只有 Node.js 中間層做 HTML 渲染了。

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

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

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

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

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

你說(shuō)是吧。

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

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

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

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

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

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

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

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

首屏渲染

SEO

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

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

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

對(duì)于前端，特別是互聯(lián)網(wǎng)公司的前端來(lái)說(shuō)，那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ì)于本身工作超飽和還找不到人的前端來(lái)說(shuō)能按時(shí)寫完功能，后端哥哥按約定完整交付接口不扯皮就已經(jīng)不錯(cuò)了。任何應(yīng)用都是最先保證功能的上線，優(yōu)化什么的都是后話。從此，前后端開始分離。

再往后node有了，理論上來(lái)說(shuō)，可以做到SSR和CSR都由前端維護(hù)，但對(duì)于歷史悠久底子薄的JS生態(tài)圈來(lái)說(shuō)，同構(gòu)技術(shù)依然還是匱乏的，CSR和SSR分別維護(hù)兩套代碼怎么想都很惡心，干脆就還是繼續(xù)CSR好了，直到以REACT為代表的渲染庫(kù)出現(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（或者說(shuō) Full-stack）工程師負(fù)責(zé) SSR，但是現(xiàn)在是 Front-end 工程師負(fù)責(zé) SSR 了啊。在目前這個(gè)知識(shí)爆炸的年代，前后端的職能目前已經(jīng)被分割得很開，大家都不愿意去淌對(duì)方那攤混水，而 Rendering 這事從語(yǔ)義上出發(fā)就屬于 Front-end 的范疇，讓 Back-end 去做這事，其實(shí)很多人是不愿意的。

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

而隨著 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 來(lái)實(shí)現(xiàn) SSR 了，于是 React 和 Vue 等主流框架后面開始支持 SSR 也就成了必然。

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

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

作者：代碼灣

來(lái)源：CSDN

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

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