渲染谱

以下是网站渲染的主要类别

• 客户端：发送一个 <div id="root"></div> 并让 JavaScript 模板渲染所有内容。
• 静态：预渲染 HTML。
• 服务器：让活动服务器处理请求并生成 HTML 响应。

它们不是相互排斥的。

• 一个网站可以静态预渲染 75% 的页面（例如，博客文章），但另外 25% 的页面则由服务器响应（例如，论坛）。
• 一个网站可以静态预渲染所有页面，但在其中包含几个空的 <div>，这些 <div> 中包含客户端渲染的内容（例如，根据登录用户动态生成的菜单）。
• 一个网站可能主要由服务器渲染，但在其前面有缓存，因此其行为类似于静态渲染。
• 一个网站可以静态渲染，然后“水化”成一个完全由客户端渲染的网站。
• 一个网站可以混合使用服务器和静态渲染，但具有类似于客户端渲染的动态部分，但实际上发生在边缘函数中，因此最终更像服务器端渲染。

Next.js 很有趣，因为它可以同时执行这三种操作。 以下是 Tim Neutkens 在 最近的一次采访中所说的话

Next.js 允许您预渲染页面。 它在构建时使用静态站点生成在服务器上创建 HTML，或者在服务器端使用运行时渲染。 Next 允许您混合使用这些方法。 与大多数其他框架不同，您不受限制，例如，我将完全静态地生成我的应用程序。 相反，您可以让某些页面进行服务器端渲染，而某些页面进行静态生成。

在新版本中，我们使得能够更新这些静态生成的页面，而无需运行新的构建，重新构建整个应用程序。

酷。 非常乐意看到这种情况发生在框架级别。 对于许多网站来说，似乎必须全力投入一种渲染风格是不切实际的。

客户端渲染最灵活，但存在所有这些严重的缺点，例如性能下降、可靠性下降、对设备的压力更大、SEO 不佳等。 静态预渲染最健壮、速度最快且最安全，但限制最大。 基于静态的边缘函数开始打开大门，但服务器渲染是经典的灵活性和速度的结合，长期以来一直主导着网络，这是有充分理由的。

客户端渲染还为“SPA”（单页应用程序）体验打开了大门。 我个人仍然喜欢它。 我喜欢没有页面刷新的感觉。 它使网站感觉敏捷，并为页面过渡打开了大门。 Gatsby 因普及水化而闻名，您可以在其中获得预渲染静态的额外好处，然后随着 JavaScript 下载升级到 SPA。

我希望看到网络发展到我们能够获得 SPA 的所有“良好体验”额外好处，而无需实际构建 SPA 的程度。 当框架提供 SPA 体验而无需自己管理太多内容时，这一点很值得注意，但仍然，某些东西正在管理它，而这个东西是一堆 JavaScript。

Tom MacWright 最近在他的 “如果不是 SPA，那是什么？” 文章中写到了这一点。 今天的一些替代方案

Turbolinks … 为了获得 SPA 体验而无需应用程序的任何配合，您需要做的最少的事情是什么？

Turbolinks 就像……点击链接，点击被拦截，发出新页面的 Ajax 请求，JavaScript 使用新内容在页面上显示内容。 非常易于实现，但它仍然是 JavaScript，并且在发送更少的数据方面并不特别智能。

barba.js 和 instant.page 是针对同一类问题的替代方法。

Barba 完全专注于页面过渡（有关该概念的更多详细信息）。 instant.page 完全专注于在您点击之前预加载/渲染页面，因此即使您获得页面刷新，它也感觉不那么突兀（尤其是在使用 绘制保持 的情况下）。 两者都很酷，但并不是 SPA 的一对一替代品。（即使使用绘制保持、预渲染和轻量级页面，我认为体验仍然不如 SPA 流畅。 例如，您仍然会看到页面加载微调器。）

那么……还有其他正在开发的东西吗？ 算是吧。 有 <portal>。 可能过于简化，但还是说一下：门户就像 iframe。 它们甚至可以像 iframe 一样进行视觉显示。 这意味着门户中 URL 的渲染已经完成。 然后，您可以“提升”门户以成为活动页面，甚至在执行此操作时对门户本身进行动画处理。

我不讨厌它。 我可以想象有人在门户上构建一个类似于 Turbolinks 的库，以便它们“易于使用”并使网站更像 SPA。

尽管如此，将矩形动画到某个位置通常并不是页面动画过渡所需的。 只需看看 Sarah 的“Web 上的原生动画页面过渡”文章。 这就是人们想要的（至少是可能性）。 这就是为什么 Jeremy 前几天在俏皮地说“[m]ost single page apps are just giant carousels.”时说不是门户。 他还指出了 Jake 几年前提出的 navigation-transitions。

我非常喜欢这个提案。 它专注于用户需求。 它还询问了为什么人们选择 JavaScript 框架而不是使用浏览器提供的功能。 人们选择 JavaScript 框架是因为浏览器尚未提供某些功能：例如选项卡或手风琴之类的组件；DOM 差异；控制复杂表单元素的样式；导航过渡。 JavaScript 框架今天正在解决的问题应该被视为未来 Web 标准的研发部门。（反过来，我坚信任何好的 JavaScript 框架的目标都应该是让自己变得多余。）

那么，最佳渲染方法是什么？ 对您最有效的方法，但也许像这样的层次结构在某种程度上是有意义的

1. 尽可能使用静态 HTML
2. 使用边缘函数处理静态 HTML，以便您可以执行任何动态操作
3. 在之后使用服务器生成的 HTML
4. 仅在绝对必要时使用客户端渲染