惯性

我一直很喜欢 Jeremy 对开发者工具的分类

我提到了两种用于 Web 开发的工具类别。我仍然不太清楚如何称呼这些类别。内部和外部？面向开发人员和面向用户？

第一类包括构建工具、版本控制、转译器、预处理器和代码检查器等。这些工具驻留在您的机器上——或服务器上——获取您编写的代码并将其转换为 Web 的原材料：HTML、CSS 和 JavaScript。

第二类工具是由 Web 的原材料制成的：CSS 框架和 JavaScript 库。

这是一种很好的思考方式。当然，也存在细微差别。Sass 属于第一类，因为它永远不会传递给用户，它只会生成传递给用户的 CSS。但它仍然会影响用户，因为它可能会根据您的使用方法生成大小不同的 CSS。

Jeremy 将 Svelte 称为一个库，其目标是在代码传递给用户之前尽可能多地编译自身。仍然会存在一些 JavaScript 代码，但它不包含面向开发人员的 API 的开销。这里的细微差别在于，Svelte *可以* 以一种完全删除所有 JavaScript 代码的方式使用。例如，SvelteKit 可以 完全关闭其水合功能 并进行页面预渲染，从而创建一个完全无 JavaScript 的网站（或者至少只在您需要时选择它）。

关于 React

我知道有一些方法可以使 React 的行为更像第一类工具，但这绝对不是默认行为。而默认行为真的非常重要。对于 React 而言，默认行为是假设您编写的所有代码——以及您用来编写它的工具——都将发送到最终用户。

我认为这么说很公平，但故事似乎也正在慢慢发生变化。我认为广泛使用还很遥远，但 服务器组件 在这里似乎值得注意，因为它们来自 React 团队本身，就像 SvelteKit 来自 Svelte 团队本身一样。

以及关于 Astro

[...] 与 Svelte 不同，Astro 允许您使用与现有的 React 相同的语法。因此，如果您已经学习了 React——因为这是您获得工作所需的学习内容——您无需学习新的语法即可使用 Astro。

我知道您可能无法一键将现有的 React 网站转换为 Astro，但至少有一条清晰的升级路径。

这不仅仅是理论上的，而且是可证明的！

我刚刚将 我们的小型无服务器微型网站 从 Gatsby 转换为 Astro。Gastby 基于 React，因此所有组件都已构建为 React 组件。 Pull Request 比较混乱，但它在这里。 我将其中一些内容转换为 .astro 文件，但将许多组件基本保持不变，作为 .jsx React 组件。但是 React *不会* 将其发送到用户。网站上的 JavaScript 几乎完全被移除，除了 一些为实现非常轻量的交互性而编写的原生 JavaScript。

因此，这里发生了一些抛硬币的事情。合并硬币？对我来说，Astro 感觉非常像一个面向开发人员的工具。它帮助*我*。它使用 Vite 编译器，并且使用起来非常快速且愉快（Astro 肯定还存在一些粗糙的边缘，因为它尚未达到 1.0 版本，但 DX 在很大程度上已经存在）。它限定了我的样式。它允许我编写 SCSS。它允许我编写组件（使用许多*不同*的框架）。但它也*帮助*了用户。网站上根本没有 JavaScript 包。

我想这意味着 Astro 并没有改变类别——它是一个面向开发人员的工具。它只是碰巧将原本面向用户的工具（甚至是 Svelte）变成了几乎完全面向开发人员的工具。

---

因为我口袋里还有几个其他的 Astro 链接在燃烧，所以 Flavio 有一个 不错的入门教程，以及 Drew McLellan 和 Matthew Phillips 在最近一期 Smashing Podcast 中 聊 Astro。

---

还有 Dave 和我讨论我最近使用 Astro 重做的网站