我希望 Deno 能继续做它最擅长的事

# 我希望 Deno 能继续做它最擅长的事 来源：https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best ## 配置之墙https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best#019ea76d-a930-7184-8b09-e75c036c8c24--the-wall-of-configuration 多年以来我一直在用 Python 工作，周末则沉浸在 Haskell 的幻想里。写脚本时用 Python，当我想让类型系统来约束自己时用 Haskell。TypeScript 位于这两者之间，我很清楚这一点。在 Haskell 过于严苛而 Python 又缺乏类型的地方，它很实用。但我一直都和它保持距离。*tsconfig.json*、*.eslintrc*、*.prettierrc*、*babel.config.js* —— 在你写任何实际代码之前，就必须先创建这些文件。每次我考虑尝试 TypeScript，看到这一长串文件就放弃了。JavaScript 生态给我的感觉就像游乐园，你得排很长的队才能进去。 Deno 消除了这个排队的过程。没有配置文件、没有 *node_modules*、不用纠结该用哪个包管理器。只需要 `deno run main.ts`。我第一次真正顺畅地写 TypeScript 时，完全不明白自己为什么拖延了这么久。我一直回避的不是 TypeScript，而是 TypeScript 周围那一套繁琐的仪式。 ## 吸引我的地方https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best#019ea76d-a930-7184-8b09-e75c036c8c24--what-hooked-me 起初我说不出某个杀手级功能。它的吸引力在于所有东西都朝着同一个方向努力。我在浏览器里使用的 `fetch()` 在服务端行为完全一样。Web Crypto API 开箱即用。MDN 实际上成了 Deno 的文档。你不需要安装包，而是通过 URL 导入 ESM，以完全不同的方式思考依赖关系。 `deno fmt`、`deno lint`、`deno test`、`deno bench` 和 `deno check` 全都在一个二进制文件里，也是同样的逻辑。无需安装 ESLint，无需配置 Prettier，无需理清两者之间的配置冲突。这种便利背后其实有一种态度。 模式很明显：建立在 Web 标准之上，然后自己打包好那些枯燥的工具。 ## 追赶 Node.jshttps://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best#019ea76d-a930-7184-8b09-e75c036c8c24--chasing-node-js 如今的 Deno 感觉正在偏离这个方向。 `npm:` 说明符支持、*node_modules* 重新引入、`node:*` 模块兼容性。然后在 Deno 2.8 中，不带说明符的 `deno add` 现在默认添加的是 npm 包。JSR 最初被推出作为对 npm 停滞不前的回应，是 JavaScript 打包的未来。但这些决策让那个宣告显得很遥远。单独看每个决策我都能理解。但把它们放在一起，就很难忽视这个形态：Deno 正投入越来越多的精力去追赶 Node.js。 这让我想起了 OS/2 的故事。IBM 期望在 OS/2 中构建 Windows 兼容性，能够把 Windows 用户吸引过来。但实际效果恰恰相反：开发者意识到他们可以只针对 Windows 开发，程序就能在两个平台上运行，因此没有理由单独学习 OS/2 API。Deno 进一步推动 Node.js 兼容性，也有着同样的动态。Deno 变得越兼容，库作者就越没有理由特意为它考虑。 与此同时，Node.js 一直在向 Deno 靠近。TypeScript 在 v22 中无需额外标志即可运行。（https://nodejs.org/api/typescript.html）权限模型在 v20 中引入。（https://nodejs.org/api/permissions.html）`fetch()`（https://nodejs.org/api/globals.html#fetch）和 Web Crypto API（https://nodejs.org/api/webcrypto.html）现在都已经支持。`node:test`（https://nodejs.org/api/test.html）和 `node:assert/strict`（https://nodejs.org/api/assert.html）已经悄然成为针对 Deno、Node.js 和 Bun 项目的最佳跨运行时测试工具。这两个运行时正在趋于一致，但 Deno 似乎付出了更多努力。 早期的 Deno 设定了议程。Web 标准、权限模型、URL 导入、JSR：Deno 提出了这些想法，生态系统做出了响应。而 Deno 现在做的事情正好相反——追赶生态系统已有的东西。 ## 处于守势https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best#019ea76d-a930-7184-8b09-e75c036c8c24--on-the-defensive 这里还有一种更具体的挫败感。Deno 本可以领导一场战斗，而不是去追逐。 当初让我远离 JavaScript 生态的不是 Node.js 本身，而是完整的组合：Node.js + npm + TypeScript + Vite + ESLint + Prettier + Vitest。这套工具链才是问题所在，而 Deno 原本已经在这方面做得很好。`deno fmt`、`deno lint`、`deno test`、`deno bench`、`deno check`，还有在 2.4（https://deno.com/blog/v2.4）中回归的 `deno bundle`。它曾经被弃用后来又被恢复；这个来回本身就承认了那个方向是对的。 目前最明显的缺口是开发服务器：HMR、热重载、资源管道，以及建立在这些之上的插件生态。Deno 自己的框架 Fresh 2.0 选择不通过 Deno 内部来填补这个缺口，而是采用了 Vite。（https://deno.com/blog/fresh-and-vite）这让我很失望。让 Vite 在 Deno 上良好运行，和让 Deno 成为一个自给自足的开发环境，是两个完全不同的方向。一旦你自己的框架做出了这种选择，你就不能指望更广泛的生态系统会走向另一边。 但垂直整合本身可能还不够。单个组件的质量也很重要。如果 `deno lint` 和 `deno fmt` 明显优于 ESLint 和 Prettier，那么即使是 Node.js 项目的开发者也会倾向于使用它们。这本来可以成为特洛伊木马。一旦有足够的项目在没有 Deno 运行时的情况下使用 Deno 的工具，接下来的问题就顺理成章了。ESLint 和 Prettier 看似不可动摇，但 Biome 和 Ox 系列（Oxlint、Oxfmt）正在站稳脚跟。这个市场一直都在。只是之前缺少更好的工具。Deno 本可以率先抢占。 ## 我一直惦记的那口钟https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best#019ea76d-a930-7184-8b09-e75c036c8c24--the-clock-i-keep-thinking-about 为什么 Deno 没有坚持原来的路线？这只是猜测，但这是我的理解。 集成工具链的道路需要耐心。让开发者感受到配置复杂性的痛苦，让 Deno 成为他们迁移的目的地，等待生态逐渐适应 Deno 的方式——所有这些都需要时间。Node.js 是一个 OpenJS 基金会下的社区项目，没有投资者的时钟在推动它，即使生态发展缓慢，项目也不会动摇。 Deno Land Inc. 不同。一家由风险投资支持的公司自有其时间压力。这种时间压力允许进行持久战的程度，与社区项目所能承受的不同。扩展 Node.js 兼容性比缓慢的替代方案能更快产生可见的成果。从外部来看，我无法区分哪些是产品决策，哪些是融资决策。我只能说，Deno 最近展现的紧迫感，与它最初选择的方向并不协调。 ## 即便如此https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best#019ea76d-a930-7184-8b09-e75c036c8c24--even-so 尽管我抱怨了这么多，我自己的库大部分还是以 Deno 优先的方式构建的。即使我也发布到 npm，我仍然会发布到 JSR。我尽量只依赖 Web 标准 API，并使用 Deno 内置的工具进行 lint 和格式化。我仍然支持 Deno。 但就连我在某些地方也有所退让。现在我用 `node:test`（https://nodejs.org/api/test.html）和 `node:assert/strict`（https://nodejs.org/api/assert.html）进行测试，因为这是在 Deno、Node.js 和 Bun 上运行相同测试的最简单方式，无需任何特殊依赖。JSR 被推出时号称是对 npm 停滞的回应，而我现在已经开始感觉 JSR 也在停滞。我经常犹豫是否要放弃它。我曾对 Deno KV 感到兴奋，现在却只是用 `node:sqlite`，它在 Deno 上运行良好。 如果像我这样的人已经开始后退，我不知道对于那些和 Deno 没有任何感情联结的人来说，Deno 又是什么样子。这让我担心，因为我仍然希望 Deno 能在某种程度上赢得这场战斗。只是近来我越来越不确定，Deno 想要赢得的，是否就是当初我选择加入的那场战斗。