渲染模式

why

开发前端项目的时候，需要考虑部署的环境，针对环境，选择何时的页面渲染模式，才能针对性的选择最合适的框架。

how

前端渲染模式的演进过程大致为：

1. 2010 年之前，传统时代，SSR 服务端渲染。主机部署
2. 2015 年左右，SPA 时代，CSR 客户端渲染。边缘部署
3. 2018 年左右，SSR 复兴时代，SSR 水合交互。主机。主机部署
4. 2018 之后，内容驱动，SSG/JAMStack 静态内容 + 少量交互水合。边缘部署，静态服务
5. 2018 之后，混合模式，ISR/边缘渲染。边缘部署，可静态可动态服务

简单地理解“边缘”，即最接近用户的服务器节点，最快响应用户，如 CDN

○ SSR

• 输入：用户请求页面
• 处理：服务端获取数据 -> 生成 html -> 返回
• 输出：用户接收 html -> 渲染

○ CSR

• 输入：用户请求页面
• 处理：服务端永远返回 index.html（非 hash 模式） -> 客户端加载对应页面 js 进行渲染
• 输出：执行 js -> 客户端渲染

○ SSR 水合

Astro：

• 输入：用户请求页面
• 处理：服务端获取数据 -> 生成 html，含 js 链接👀 -> 返回
• 输出：用户接收 html -> 渲染 -> 加载 js 岛屿 -> 再渲染

Next.js：

• 输入：用户请求页面
• 处理：服务端获取数据 -> 生成 html，含 js 链接 -> 返回
• 输出：用户接收 html（可选流式，关键内容优先） -> 渲染 -> 加载 js（优先交互中或交互可能性大的） -> 再渲染

Next.js 中有多种水合模式

○ SSG 水合

Astro：

• 输入：用户请求页面
• 处理：服务端返回预生成的 html，含 js 链接 -> 返回
• 输出：用户接收 html -> 渲染 -> 加载 js 岛屿 -> 再渲染

○ ISR

Next.js：

• 输入：用户请求页面
• 处理：服务端检查预生成的 html，含 js 链接 -> 页面缓存过期，服务端重新生成 -> 返回
• 输出：用户接收 html -> 渲染 -> 加载 js 岛屿 -> 再渲染

Next.js 中通过 getStaticProps 函数返回的 revalidate 缓存时间来判断是否重新生成

Astro 借助部署平台来管理缓存

Remix 借助 HTTP 缓存头实现

what

涉及服务端的边缘部署 -> SSG 水合、ISR -> 可选 Next.js，Astro 等

不涉及服务端的边缘部署 -> SSG 水合、CSR -> 可选 Next.js，Nuxt.js，Astro，Vite 构建的 SPA 等