服务器：再次酷起来

假期回来后，有人开玩笑说 JavaScript 决定完全转向服务器端。 我认为这源于

• Basecamp 团队发布了 Hotwire，这看起来像是对多种技术的营销策略。 他们说“通过网络传输 HTML”，这意味着它让服务器生成和提供 HTML，并将客户端 JavaScript 留给只有客户端 JavaScript 才能做的事情。
• React 团队 介绍零包大小 React 服务器组件，我相信这是核心项目迈向服务器端一切的第一步。

我非常喜欢一些营销炒作，但值得注意的是，这些只是对已经成熟（我敢说老）想法的新颖诠释。

Turbo（“Hotwire 的核心”）是 Turbolinks 的进化版本，它是一个非常简单的基本理念：拦截内部链接上的点击。 浏览器不再执行完整的页面刷新，而是fetch 新页面的内容，将其放置到位，并History.pushState() URL。 现在您有了单页应用程序的感觉，但您不必构建 SPA。 如果你已经使用 ERB 模板在 Rails 中构建了你的应用程序，这非常方便。

但这实际上效率高吗？ 好吧，到目前为止它并不特别受欢迎。 之前的想法是网络是瓶颈，所以让我们通过网络发送尽可能少的内容。 “尽可能少”通常转化为 JSON。 如果你在客户端获得 JSON，现在你需要在客户端使用模板系统将其转换为可用的 DOM。 使用这种技术，你要付出两方面的代价：1) 加载客户端库 2) 数据到 DOM 的处理。 如果你通过网络发送“HTML”，你就不需要支付这两项费用（更快），但理论上会通过网络发送更庞大的有效载荷（更慢），这假设 HTML 比 JSON 更重，这是...有待商榷的。

所以...视情况而定。 这取决于有效载荷的大小以及预期对它们执行的操作。

你会期待 React 的观点是：一定要使用客户端。 但对于新的 服务器端组件预览，情况并非如此。 视频非常清楚地表明：“在服务器上渲染”组件更快，尤其是在嵌套组件情况下，其中许多组件负责获取自己的数据。 那么通过网络传输什么呢？ 是 DOM 就绪的 HTML 吗？ 不是在这里。 从视频中可以看出，网络响应是某种专有格式¹，它描述了 React 组件。 这似乎很重要，因为它意味着客户端 JavaScript 包根本不包含该组件，并且状态²可以来回传递。 Lauren Tan 在视频中也明确表示：这有点像 SSR，但与 Next.js 今天使用 SSR 的方式不同。 关键是让明天的 Next.js 变得更好。

所以：服务器。 他们只是擅长做某些事情（一位正在 WordPress 博客上打字的人说）。 确实似乎有一些趋势朝着在客户端上做更少的事情发展，我认为我们大多数人都会同意，最近客户端承担了太多责任，这导致了资产大小不断增长。

在我们继续前进的同时，让我们将这些服务器推向边缘。