与 Deno 分手了，现在 Node 才是我最好的朋友

原文 ↗ Hacker News 讨论 ↗

一篇主张“今天没有理由使用 Deno”的博文重新引发了关于 Node.js、Deno 和 Bun 这三种 JavaScript/TypeScript 运行时优劣的争论。评论者将 Node 的稳定性、长寿命和不断增强的内置工具（如 `node:test` 和 TS 去类型处理）与 Deno 的一体化工具链、更严格的安全/权限模型和 JSR 生态，以及 Bun 的性能宣称与开发体验进行了对比——但同时也担忧其 bug、兼容性和近期的公司风波。还有人指出，AI 编程助手现在会默认偏向流行技术栈，从而强烈影响运行时采用，这可能正在推动大家围绕像 Node 这样“无聊但稳妥”的选择进一步收敛，即便替代方案在开发体验或安全性上更好。

运行时：Node、Deno、Bun

  • 许多人把 Node 看作“无聊但稳妥的选择”：生命周期长、稳定，而且很可能比新运行时存活得更久。
  • Deno 常被认为在理念上更好、更现代，但也有人觉得它正逐渐变得默默无闻。
  • Bun 因其易用性和速度受到称赞，但也伴随着对过去 bug、Rust 重写、收购风波，以及其创始人相关政治争议的担忧。

为什么有人更喜欢 Bun

  • 被称为比 Node/Deno“更轻”：依赖更少、内置 bundler/测试工具、TS 构建简单、可单二进制部署。
  • 一些人表示其开发体验很好，也减少了对 shell 脚本的需求。
  • 也有人反驳说，在简单基准测试中 Node 的内存占用更低、CPU 表现也相近，因此质疑 Bun 的性能叙事。

为什么有人坚持用 Node

  • 被认为成熟、稳定、兼容性广；性能“够用”。
  • 有人说其他一切最终都会被 Node 的生态重新吸收。
  • 内置的 node:test 和覆盖率功能被视为改进，不过 linting/类型检查仍需要额外工具。

为什么有人仍选择 Deno

  • 其强项包括内置测试/lint/check、简单的 TS 方案、安全权限、JSR/标准库，以及可编译为单一二进制文件。
  • 桌面/WebGPU 支持和沙箱机制被强调为独特优势，尤其适合 agent/AI 使用。
  • 许多人喜欢它“一条 CLI，全家桶”的感觉，而不是 Node 那种配置/工具链碎片化。

HTTP 与兼容性争论

  • 围绕 HTTP GET 携带请求体的激烈争论：
    • 一方坚持这不符合标准且不安全；实现可以忽略它。
    • 另一方指出，广泛使用的工具（如 Elasticsearch、某些 GraphQL 客户端、基础设施工具）依赖这一行为，并预期 Node 式行为；Bun 更严格的处理被视为兼容性破坏。

TypeScript 与生态系统

  • 对文章声称 Node 的 TS 限制只是“反微软”的哲学立场存在分歧；评论者指出有具体技术原因（tsconfig 差异、性能问题）。
  • 有人认为声明文件已经解决了大多数库类型需求；也有人只是想要对 TS 源码进行简单的去类型处理。
  • 更大的分歧在于：有些人把 TypeScript/强类型视为非平凡系统的必要条件，另一些人则认为 TS 只是开销，收益有限。

LLM 与工具选择

  • 有人指出 LLM 经常默认使用 Node/Bun/Next.js/Supabase，从而推动采用。
  • 也有人认为熟练用户应该明确告诉 LLM 使用哪个运行时/技术栈；“LLM 不会主动选它”主要影响产品流行度，而不是能力。