服务器端渲染

貌似几年之前从服务端生成html(如servlet)慢慢开始前后端分离，把一些渲染计算的步骤抛向前端来减轻服务端的压力。但是为啥现在又开始流行在服务端渲染html了呢？如vue全家桶或者react全家桶，都是推荐通过服务端渲染来实现路由的。单纯的是因为Virtual DOM的强大还是别的什么原因？

1.方应杭

这要从大概八年前说起，事情是这样的

1 一开始，html 就是后端渲染的。不过后端发现页面中的 js 好麻烦（虽然简单，但是坑多），于是让公司招聘专门写 js 的人，也就是前端

2 前端名义上是程序员，实际上就是在切图（CSS）和做特效(JS)，所以所有 程序员 中前端工资最低，职位也最低。所以前后端的鄙视链就出现了。

3 nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，于是全力支持这两种技术，造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，实际上是为了「人员分离」，也就是「前后端分家」，前端不再附属于后端团队）

4 spa 之后发现 seo 问题很大，而且首屏渲染速度贼慢，但是自己选的路再难走也要走下去，于是用 nodejs 在服务端渲染这一条路被看成是一条出路

5 其实这是第二个翻身的机会，如果 nodejs 服务器渲染成为主流，其实就相当于前端把后端的大部分工作给抢了，工资压过普通后端指日可待

6 然而结果是 nodejs 服务端渲染始终是小众，因为后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 做渲染（比如阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。

7 于是 nodejs 退一步说好好好我不抢你们的工作，我只做中间层（大部分工作就是渲染页面和调用后台接口），绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。

你要看一门技术的发展主要应该看背后的人是谁，应用场景是哪些，最后才是技术细节。

nodejs 的火在中国早就烧过了，以后估计不会大火了，作为前端了解一下还是不错的，但是如果你是后端的话，看不看都无所谓，nodejs 跟其他后端开发框架差异并不大，单线程异步既是优点也是缺点，你就把它当做一种范式研究就好。

我是一个坚定的『前后端分家』反对者，前后代码可以分离，但是人员绝对不应该分离。前后端撕逼的事情在大公司天天都在发生，全都是因为前后是两个团队，利益不同。实际上前端推 nodejs 渲染就是在试图重新让前后端合成一体。

但是前端不能明说这件事，因为如果要把前后端部门合并，拆掉的肯定是前端部门。

合，则相当于自断前程。

不合，则永远没法解决seo和首屏加载慢的问题。

所以前端真的挺矛盾的。

JS 也有一个矛盾的地方，凡是浏览器上的框架（Vue React）都说自己能适应「复杂」场景，凡是 Node.js 上的框架（express fastify koa）都说自己是「轻量级」框架。

为啥？因为浏览器是 JS 的主战场，而且无敌手。而服务器上，JS 的经验积累还是太少了，搞企业级服务，Node.js 是敌不过 Java 、PHP 的，没办法，发展得太晚了。所以目前只能搞「轻量级」咯。egg.js 号称是企业级 Node.js 框架，用过的人来评我就不评了。

有些大佬提出「大前端」的概念，意思是前端也要会后端，但是我们心还是前端的。

这不就是把以前的『前后端一个人做』换了个说法嘛。

反正你现在让后端去学前端，后端肯定是不愿意躺这浑水的。只能前端自己想办法咯。

想来想去就只有 Node.js 中间层做 HTML 渲染了。

当初是你要分开，分开就分开。

现在又要用kpi，把我唤回来。

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

这些话也就我这种不在大厂的人敢说，在大厂的人根本不敢说，毕竟跟后端低头不见抬头见的。

最后告诉你一个小秘密。由于阿里 nodejs 用得还算多，却招不到人，所以从功利的角度出发，也许你学 nodejs 比学 java 更容易进阿里，毕竟阿里的 java 大神多如云，nodejs 大神却不多。

你说是吧。

但是从另外一个角度考虑，SEO 不友好的页面我是支持的。

如果你的页面是对 SEO 不友好的，那么百度的重要性就会被削弱。现在是移动互联网时代，大家在手机上几乎不用百度，都是直接点 App 点微信公众号的，SEO 不友好问题不大。首屏速度随着 5G 网络的普及也不会是问题了。

只要能让百度利益受损，我觉得 SPA 这事还是值得做的。服务端渲染还是直接免了吧，大家都不做 SEO 让百度倒闭就最好咯~（只是我的幻想而已，不要当真，我是百度的脑残黑，黑百度从来不需要理由）

感谢你看我说了这么多，不过说到最后，我也没给出啥结论，只是把我观察到的告诉你了。

你要不要学、要不要用服务器渲染HTML，都是需要你自己思考的事情。

还是那句话，我不喜欢说中庸的观点，我喜欢跟你说一个极端的观点，然后会有人用另一个极端的观点反驳我，他说服不了我，我也说服不了他，但是最终，你会得出自己的观点。

2.张强张耳朵

SSR的好处无非就2点

首屏渲染

SEO

然而这2点从来都很重要，可为啥之前有段时间不流行SSR呢？

往早了说，因为JS慢，网络慢，客户端本身也很慢，所以为了让功能可用且保证基本的流畅，前端就纯展示好了，交互非常少，渲染的活就交给server吧，因为当时前端很薄，所以很多前端的活都是后端兼的（那时候好像不怎么区分前后端，大家都是web开发工程师，按现在的说法叫全栈工程师）。

再后来，js快了，网络快了，客户端本身性能也高了，所以我们可以往客户端堆各种复杂的功能逻辑和交互，需求和工作量double后你让一个web开发工程师干2个人的活感觉身体要被掏空，所以一部分人选择了js专精，成为了专职前端。

对于前端，特别是互联网公司的前端来说，那UI的变更迭代的频率不知道要比业务逻辑本身高到哪里去了，产品动不动就要改UI改交互，这时候本身疲于需求变更的前端还要去求后端哥哥帮你上线新html模板，后端哥哥本身并不关心你html的dom怎么编排，还得每次都要人肉配合你改，真是苦不堪言+一脸嫌弃。

刚好这个时候智能手机火了，SEO感觉并不怎么重要，3G网络好像也还行，除了首次加载慢之外其他时间的渲染体验慢的并不明显，那么好了，还要啥SSR，大家都CSR好了，对于本身工作超饱和还找不到人的前端来说能按时写完功能，后端哥哥按约定完整交付接口不扯皮就已经不错了。任何应用都是最先保证功能的上线，优化什么的都是后话。从此，前后端开始分离。

再往后node有了，理论上来说，可以做到SSR和CSR都由前端维护，但对于历史悠久底子薄的JS生态圈来说，同构技术依然还是匮乏的，CSR和SSR分别维护两套代码怎么想都很恶心，干脆就还是继续CSR好了，直到以REACT为代表的渲染库出现，才使得前端步入同构时代，这时候SSR的成本比以前低了一倍，自然前端们又要开始跃跃欲试提出了新的KPI指标。也就是为什么现在又开始流行服务端渲染的原因。

其实整个历史的进程可以总结为以下脉络：

硬件/带宽/JS引擎的提速–>前端逻辑变的复杂–>前后端分工–>前后端分离–>html姓”前”–>如何渲染html要跟随前端技术栈的发展节拍–>等待前端相关技术成熟–>又流行SSR

3.nekocode

「又流行」感觉像是开历史的倒车，但其实并不是。以前是 Back-end（或者说 Full-stack）工程师负责 SSR，但是现在是 Front-end 工程师负责 SSR 了啊。在目前这个知识爆炸的年代，前后端的职能目前已经被分割得很开，大家都不愿意去淌对方那摊混水，而 Rendering 这事从语义上出发就属于 Front-end 的范畴，让 Back-end 去做这事，其实很多人是不愿意的。

回到问题本身，SSR 的「又流行」其实是 Front-end 社区 工具 栈不断进化的体现，也是历史的必然啊。几年前，SPA/CSR 概念的大热，让很多 Front-end 把他们当做万金油了。其实大家都知道 CSR 有着 SEO 的问题，而且页面渲染速度肯定比不上 SSR，但苦于社区中没有解决这个问题的工具栈，所以大家都对这个问题视而不见了。

而随着 Front-end 社区造轮子大潮的兴起，出现了一个很关键的历史转折点 —— Node.js 的出现。Node.js 赋予了 Front-end 在服务端执行 Js 的能力，有了这个环境和土壤，Front-end 工程师们终于可以考虑如何用 Js 来实现 SSR 了，于是 React 和 Vue 等主流框架后面开始支持 SSR 也就成了必然。

所以之前并不是不流行，而是因为前后端职能的分离，Back-end 不愿意做这事了，Front-end 没有条件去做。现在有条件了，自然又开始流行了。

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

作者：代码湾

来源：CSDN

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

版权声明：本文为博主原创文章，转载请附上博文链接！