新时代的 SSR 框架破局者：qwik( 二 ) _SSR

当然 CSR 还存在一些其他方面的缺点，比如网站强依赖于 JS 当用户禁用 JS 时网站只能是白屏展现给用户等等之类。
1.2 Server Side Render简单聊完客户端渲染后，我们稍微来看看所谓的服务端渲染是什么含义。
基于旧时代的类似 Java 的 JSP 页面我在这里就不赘述了，显然 JSP 的方式每个 HTML 都需要单独请求服务器返回对应的 HTML 内容严格意义上来说这也是 SSR 的方式但是很明显这已经被时代淘汰了。
目前国内各家公司广泛应用的服务端渲染技术大概的思路是这样的（Next 的 SSR 模式也是同样的思路）：
当用户首次访问你的应用站点时：

首先服务器会根据对应的 URL 在服务端根据对应路径渲染对应的 HTML 模版。注意这里渲染的 HTML 模版是具有该页面真正的内容。同时它并不具备任何交互逻辑（比如 DOM 元素的点击事件），这是一份完全的静态站点。
服务器会下发这份仅具有静态内容的 HTML 模版，同时这份模版中也会包含对应的 JavaScript 执行脚本。第一时间会展示给用户对应的 HTML 页面，此时对于访问站点的用户来说首屏渲染相较于 SPA 应用来说会非常快。因为它并不需要在客户端浏览器上再次下载和执行 JavaScript 脚本来进行页面渲染。
其次，针对于 SEO 的优化也会非常良好，因为服务器上下发的 HTML 页面是包含当前站点的真实 HTML 结构，对于搜索引擎的爬虫来说会非常容易的匹配到当前关键字。
之后，浏览器会下载当前这份 HTML 的 JS 脚本。
因为首先呈现给用户的一份静态的 HTML 页面，并不具备任何交互效果。我们需要为页面上的元素增加对应交互，HTML 页面中的 JS 脚本中会包含网站的交互逻辑。
最后，当下载完 HTML 脚本中的 JS 脚本后，自然会执行这些 script 脚本。从而发生一种被称为 # hydrate(水合) 的方式，从而为页面上静态 HTML 元素再次添加对应的事件处理从而保证页面具有交互性。

当 hydration 过程完成后，会由我们的客户端框架接管网站的后续渲染。在后续的导航链接跳转和页面渲染中和服务器已经没有任何关系了，我们完全可以利用客户端的路由切换（History Api/Hash Api）利用 JS 进行页面渲染从而保证切换页面不用再次请求浏览器保证非常及时的页面交互。
1）hydration
上述过程中有一个非常重要的关键字 hydration（水合）。
首次访问页面时，页面的静态 HTML 是在服务端生成的。在服务端我们将生成的静态 HTML 以及 HTML 中携带的 JS 脚本发送到客户端。
此时静态 HTML 会立即显示在用户视野中，然后浏览器会利用网络进程下载当前 HTML 脚本中的 JS 脚本。
当 JS 脚本下载完成后，会立即执行同时发生一种被称为 hydration 的过程。
所谓的 hydration 简单来说，也就是客户端下载完成 JS 脚本后，浏览器会执行下载的 JS 脚本这些脚本中有部分内容会将已经存在的 HTML 内容通过执行下载的 JS 脚本添加上对应的事件监听器从而保证页面的交互。
注意，在 React、Vue 中 hydration 并不意味着重新渲染。因为在 Server 端已经渲染了和 Client 完全相同的 DOM 结构所以完全没有必要在此重新渲染。
所以 hydration 的过程是给当前页面中已经生成的 HTML 页面添加上对应的事件监听器。
这也是为什么在 Next 等框架中为什么必须要保证 Server 端和 Client 的渲染 HTML 结构必须一致的原因。
比如我们以 Next 举例来说（Vue 也是同样的道理）：

当用户访问 ?www.trip.biz? 时，服务端接收到请求调用 ReactDOMServer.renderToString() 生成当前页面的 HTML 静态结构。
服务器会下发这个 HTML 页面给客户端，同时这个 HTML 页面上也会携带一部分 JS 脚本 script 标签。
用户的浏览器中会立即展现到该 HTML 页面，同时也会下载对应 JS 脚本并执行。
当 JS 脚本执行完毕后，客户端会调用 ReactDOM.hydrate() 发生水合为当前页面的 HTML 页面添加事件交互处理，同时后续由 JS 接管页面的跳转渲染。

针对于第一步 Next 中存在 ??Automatic Static Optimization?? 的优化，并不一定会在每次访问时调用 renderToString 方法，有可能在构建时也会直接生成对应的 HTML 模版。