您的未来会是 0kb JavaScript 吗？

渐进增强

React 服务器组件

岛屿

部分补水

那么 0kb？

回答回复：如何让屏幕阅读器读取文档加载和文档加载？

最近一段时间，“零 JavaScript”成了 JavaScript 库里的新热词。我觉得是时候正视这个“房间里的大象”（或者说，房间里没有大象）了。每个库都在谈论一些微妙的不同的东西，这有时让人难以辨别究竟发生了什么。所以，让我们看看能否给出一些清晰的解释。

首先，回答这个问题。可能不是。并非如此。我们并没有从根本上改变事物的运作方式。JavaScript 之所以能达到今天的水平，并非像某些批评家所说的那样，纯粹是出于不计后果的抛弃。

在网页上使用 JavaScript 的理由很充分。JavaScript 可以对用户体验产生非常积极的影响。更流畅的过渡、更快的动态内容加载、更好的交互性，甚至提升可访问性。

那么当人们谈论 0kb JavaScript 时他们在谈论什么？

渐进增强

在过去的一周里，我看到了不止一个，而是两个演示，展示了 HTML 表单如何在页面上没有 JavaScript 的情况下执行 POST 请求。Remix Run和SvelteKit都能够服务器渲染页面，并且表单无需加载 JavaScript 包就能完美运行。

不出所料，链接（<a>锚标签）在这种情况下也能正常工作。这并非突破性的，每个服务器渲染库如果设计自己的 API 来处理表单提交，都可以从中受益。但这绝对是一个令人惊叹的演示。

剧透预警 -我特别喜欢 Remix Run 的演示，他们在前 30 分钟没有告诉观众他们没有向浏览器发送任何 JavaScript。我们只是假设他们正在构建一个客户端应用。

Svelte 的创建者 Rich Harris在 4 天前就做过一个非常类似的演示。我并不感到意外，因为这是 Web 的核心基础，即使有了 React，一些不太流行的框架多年来也一直在做同样的事情。

对于我们大多数人来说，我们可能不需要迎合 no JS。Ryan 和 Michael 在他们的视频中反复提醒我们，虽然这很酷，但好处是，通过使用内置的平台机制，他们可以简化开发者需要编写的逻辑。

渐进增强的最大优点是它适用于所有框架。它内置于浏览器。更多元框架应该会支持这一点。最终，你可能仍然需要发送 JavaScript。不必这样做很酷。但这对每个页面来说，是一种“全有或全无”的策略。

React 服务器组件

这个声明绝对是开创性的。React 中仅在服务器端渲染的组件。这些组件被宣传为零 bundle 大小的组件。

零 bundle-size 到底是什么意思？嗯，这意味着你不会将这些组件随 bundle 一起打包。记住，渲染后的模板最终会以序列化格式到达浏览器。不过，你确实省去了发送 React 代码来渲染模板的时间。

服务器组件是无状态的。即便如此，对于像 React 这样的库来说，不进行打包也能节省大量成本，因为 React 的代码会随着模板大小而扩展，因为它会逐个创建 VDOM 节点。而像Lit或Solid这样的框架中的无状态模板，只不过是在其自身之上克隆了一行 DOM 模板，而模板本身无论如何都需要被发送。

更好的视角是将其视为一种新型的集成 API。至少，您在这里省去了加载数据后针对特定组件进行的数据处理。React Server 组件让您可以自然地为每个组件创建一个完全根据该组件需求量身定制的 API。可以这么说，该 API 可能只是包含一些标记。

这意味着浏览器中不再需要 Lodash 或 Moment。这是一个巨大的胜利。但真正的好处在于更容易避免性能悬崖。我们本来可以避免通过 API 发送大部分此类信息，但我们需要自己编写这些 API。

我们得到的是一种不同的代码拆分和 API 编写方式。我们确实减轻了一些代码重量，但零包大小并不意味着零体积。

岛屿

大约一年前，Preact的创始人 Jason Miller正在为一种已经存在多年却鲜有人讨论的服务器渲染方法寻找合适的名称。最终，他选择了Isl​​ands Architecture。

这个想法相对简单。不像 JavaScript 框架中常见的那样，用一个应用程序控制整个页面的渲染，而是设置多个入口点。这些交互孤岛的 JavaScript 代码可以发送到浏览器并独立处理，而其余大部分静态页面则以纯 HTML 的形式发送。

这算不上什么新主意，但最终它还是有了个名字。可以想象，这大大减少了页面上 JavaScript 的数量。

Astro 是一个建立在这一思想之上的多框架元框架。

这样做的好处在于，我们可以主动减少页面发送的 JavaScript 代码，同时保持页面的交互性。但代价是，这些应用是多页（服务器路由）的。没错，你可以构建一个单页应用，但这会抵消这些好处。

公平地说，任何 0kb 的 JS 应用都必须作为单独的页面运行。而 Astro 的 0kb 只是省去了客户端组件的麻烦。像上面提到的渐进式增强功能是自然而然的。

所以，Islands 无疑是一种减少 JavaScript 代码量的方法，你最终可能会在需要的地方获得 0kb 的 JavaScript 代码。在不需要的地方，你也无需加载不必要的 JavaScript。而且，有了 Astro 这样的库，你还可以使用自己熟悉的工具。

部分补水

部分水合与岛屿的建筑非常相似。最终的结果是互动岛屿。

区别在于创作体验。您无需编写静态层和 Island 层，而是像编写单个应用一样编写代码，更像一个典型的前端框架。Partial Hydration 可以自动为您创建 Island，以便将最精简的代码发送到浏览器。

Marko是一个鲜为人知的瑰宝（于 2014 年发布！），它是一个 JavaScript 库，它使用其编译器来自动化此部分水合过程，以从浏览器包中删除仅由服务器渲染的组件。

除了维护单个应用程序所带来的 DX 方面的好处之外，这还开启了组件之间协作的潜力。渐进式（流式）渲染就是这样一种应用。

这样的加载体验可以在客户端和服务器之间协调，而无需向浏览器发送 JavaScript 包。即使您的页面数据是增量加载的，也并不意味着它需要 JavaScript 库。Marko 的无序流式渲染带有后备占位符，需要在页面上嵌入 JavaScript，并在渲染时进行内联。然而，在按顺序渐进式渲染中，无需 JavaScript 也能正常工作。

注意此Hacker News Demo的客户端加载状态，然后打开网络选项卡即可看到缺少已发送的 JavaScript。

最酷炫的是浏览器会保留导航，直到页面开始加载。页面可以快速加载静态内容，并且无需 JavaScript 包即可获得类似客户端风格的进度指示。

总体而言，Partial Hydration 扩展了 Isl​​ands 的优势，可以将您的页面视为单个协调的应用程序。

那么 0kb？

也许并非如此，但所有这些方法和库都带来了一些好处。JavaScript 带来了很多价值，但我们并不需要在所有地方都用到它。在 React 或 Svelte 的基础上添加新的服务器利用方法，可以帮助减少一些不必要的臃肿，而无需从根本上改变开发者的体验。

孤岛方法允许希望在无/低 JavaScript 模式下运行的应用程序以增量方式运行，而无需为每个页面购买全部或全部。我们甚至可以在不发送 JavaScript 包的情况下实现动态加载。

真正的赢家是开发者。所有这些方法都为我们提供了简化客户端-服务器交互的工具。这才是我们尝试将更多功能迁移到服务器时面临的真正挑战。而这才是真正令人兴奋的部分。