【摘录】前后端分离多年，为何服务端渲染重回风口浪尖？
# 什么是服务端渲染？
咱们先搞明白个事儿，啥叫服务端渲染？服务端渲染的全称是 Server-Side Rendering，简称SSR。
简单说，就是在服务器上把网页生成好，整个的HTML页面生成出来，生成出的页面已经包含了所有必要的数据和结构信息，然后直接发给浏览器进行展现。
这和现在流行的前后端分离设计有很大的区别，在前后端分离中，浏览器首先加载到的是一个基本的框架或者说是空壳页面，随后前端通过异步请求后端API获取到数据，然后再动态构建HTML，最后再让浏览器把页面逐渐展现出来。
# Web的发展历程
要深入理解服务端渲染为何又成为热点，我们需要回顾Web的发展历史。
**早期Web开发（1990年代至2000年代初） ：**在Web的早期，除了静态页面外，大多数网页的HTML是通过服务端渲染的。ASP、JSP、PHP等脚本语言盛行，它们通常将业务逻辑和HTML模板结合在一起，以处理请求并生成完整的HTML页面返回给客户端。在这个阶段，前后端技术混合使用，开发者往往需要同时具备前端和后端的技能。
**AJAX的崛起（2005年左右） ：**Ajax技术的发展和jQuery库的普及使得网页能够动态加载数据，实现局部内容的更新，无需刷新整个页面。这一变化增强了前端的交互能力。尽管如此，服务器端渲染仍是主流，前后端职责分离尚未明显。
**前端框架的诞生（2009年以后） ：**随着AngularJS、Ember.js等前端框架的诞生，前端工程师能够创建更复杂的单页应用 (Single Page Application, SPA)。这些应用通过API获取数据，并在客户端渲染页面，显著提升了用户体验。
**现代前端框架推动的前后端分离（2013年至今） ：**React、Vue.js等现代前端框架凭借组件化和虚拟DOM等特性，极大地提升了开发效率和用户体验。同时，RESTful API的设计原则被广泛采纳，使后端更专注于提供稳定且高效的数据接口，前端则专责用户界面和交互逻辑。这种模式下，前后端的职责变得更加明确，代码重用和项目可维护性都有所提升。
那么，既然前端正在向着更加独立自主的方向发展，为何服务端渲染又重新受到关注呢？原因主要在于单页应用面临的两大挑战：
- **SEO (Search Engine Optimization) 不友好：**搜索引擎的爬虫可能无法正确地抓取和解析动态加载的内容，对于内部管理系统这没啥影响，但是网络上还有很多站点需要搜索引擎的流量支持。
- **首屏加载时间长：**用户必须等待整个JavaScript应用下载并执行完成后，才能看到页面内容，这可能会损失用户体验，特别是在弱网环境下。这为啥成为了一个问题了呢？或许是因为前端应用越来越复杂，体积越来越大，而网络传输速度和前端渲染的速度跟不上这种发展。
为了克服这些挑战，同时保留单页应用的优势，现代前端框架引入了服务端渲染功能。这样，前后端可以在某些情况下协同完成渲染任务。这种模式有效地平衡了首屏加载速度、SEO和维持单页应用的交互体验。
得注意的是，虽然从技术上看仍然是服务端渲染，但当前驱动这件事的角色实际已转变为前端工程师。在前后端分离这一架构革新之后，前端开发技术得到了迅猛发展，如今前端已经具备充分的能力来高效处理诸如SEO、页面加载性能提升等问题，这些与用户体验息息相关的交互问题正是前端的应有工作。
服务端渲染的轮回，似乎让我们看到了某种宿命，不过历史总是在曲折螺旋中上升的，或许某一天我们真的不再需要服务端渲染，这可能是因为通信能力的大幅提升，又或者是流量的某种异变，又或者某种未知改变的降临......