2023 年的 Deno

原文 ↗ Hacker News 讨论 ↗

Deno 是由 Node.js 原作者创建的 JavaScript/TypeScript 运行时，因其内置工具、以 TypeScript 为先的设计、与 Web 标准的一致性以及默认安全的权限模型而受到关注；一些开发者已经在生产环境中使用它，并使用其托管平台 Deno Deploy 和 KV 存储。与此同时，评论者质疑其长期可行性和生态锁定，担心编译后二进制体积过大、多线程选项有限以及边缘区域减少等问题，并讨论它是否真能取代根深蒂固的 Node.js，或与新兴竞争者 Bun 形成互补。新包注册表 JSR、Fresh Web 框架以及 WebGPU 支持等功能，被视为推动 JavaScript 生态前进的尝试，但也引发了对生态碎片化的担忧，以及 Deno 团队是否能够同时维持运行时和云平台的疑问。

Deno Deploy、区域与商业可行性

  • 据报道，Deno Deploy 的 GCP 区域数量从 35 个缩减到 12 个。
  • 一些人认为这对初创公司来说是合理的降本；另一些人则担心这表明增长乏力，并可能让需要特定区域的用户望而却步。
  • 还有对供应商风险的担忧：如果托管服务失败，Deno 运行时/生态系统会否存活？很多人因其开源和可自托管而认为会，但这并不能保证。

JSR 与包生态系统

  • JSR 被理解为一个以 TypeScript 为先的 JavaScript 包注册表，也是事实上的 npm 替代品。
  • 反应不一：Deno 早先的表述暗示 URL 导入可以避免需要注册表；现在它们似乎在转向，可能是从经验中吸取了教训。

Node/Bun 兼容性与价值主张

  • Deno 正在向 Node 兼容性靠拢（例如 package.json、npm 集成），部分原因是非兼容性阻碍了采用。
  • Bun 被视为更快的即插即用 Node 替代品，而 Deno 则试图用 Web 标准 API 和内置工具（TS、测试、lint、格式化、打包）来“重构 Node”。
  • 有人认为，如果 Node 也采用类似的内置能力，Deno/Bun 的吸引力将大打折扣。

开发者体验：优点与缺点

  • 支持 Deno 的观点：
    • 单一二进制安装；更新方便。
    • 开箱即用的 TS 支持，包括 REPL。
    • 合理的默认值；一个配置文件而不是一堆。
    • 内置标准库和工具减少依赖膨胀与供应链风险。
    • 适合一次性脚本和 CLI；可编译成单一二进制。
  • 批评：
    • URL 导入可能比较别扭（尤其是私有仓库）。
    • 权限模型会让人觉得繁琐；有些人最终会使用宽泛的 --allow-all。
    • 运行多个 CPU 进程/集群的能力，在裸机部署场景下不如 Node 的 cluster+pm2 方案。

编译体积与部署

  • 编译后的二进制体积从约 50MB 增长到 90MB 以上；一些人认为这对于类似 Go 的部署、serverless 限制，或许多小工具来说过大。
  • 也有人认为 90–100MB 对许多服务器/CLI 场景是可接受的，尤其考虑到其自包含性；批评者则反驳说，在 FaaS、CI/CD 和大量实例场景下，体积很重要。
  • Deno 团队成员表示相关工作仍在推进，测试中已将基础二进制体积削减了约 40%，未来还会继续改进。

框架、托管与 Next.js/Fresh

  • Deno 的 Fresh 框架被视为 Next.js 的竞争者；一些人担心它的存在会降低让 Next.js 在 Deno 上良好运行的动机。
  • 也有人认为 Next.js/Vercel 本身就高度耦合，因此 Deno 推广自己的技术栈，同时继续改进对 Next.js 的支持，是合理的。
  • Fresh 被认为很有前景，但对大型项目来说“还没完全准备好”；一些人认为 CSS 工具链（除 Tailwind/纯 CSS 之外）仍不成熟。
  • Deno Deploy 因其简洁性而受到称赞，但也因冷启动以及现在区域更少而受到批评。

Deno KV 与数据

  • Deno KV 被类比为 App Engine 的 datastore：带手动索引和事务的键值存储。
  • 它对小记录效果很好；严格的大小限制使其不适合大型 blob。
  • 线程中对 KV 的本地开发工具评价不错；生产体验提及较少，但整体偏谨慎乐观。

安全性与沙箱

  • Deno 的权限模型（默认无文件系统/网络/环境变量访问）被视为其核心差异化优势，也有助于限制第三方模块（例如只允许访问特定主机）。
  • 批评者指出，类似的隔离可以通过容器或操作系统沙箱实现；另一些人则认为，内置权限模型可跨平台工作，无需容器开销，即便在未容器化时也有价值。

多线程与并发

  • 有人提出疑问：为什么包括 Deno 在内的 Node 替代品，除了 worker 之外没有“真正”的多线程？
  • 一些人认为 JS 工作负载天然是异步的，可以利用 worker/C++ addon；另一些人则说，真正的多线程会非常有用，但要在现有异步生态中后加并不容易，且会带来数据竞争问题。

新用例与集成

  • Jupyter + Deno 受到欢迎，因为这让熟悉 JS/TS、但只偶尔处理数据的人免于 Python 依赖带来的摩擦。
  • Deno 的 WebGPU 和窗口化钩子引发了用 JS/TS 构建桌面 GUI 的兴趣，而无需捆绑完整浏览器（Electron）；不过，窗口创建和输入/无障碍功能仍依赖额外的原生库，因此这条路线尚不完整。

总体情绪

  • 许多人对 Deno 的设计、工具链和品牌表达了强烈热情，并表示其在中小型应用的生产环境中运行顺畅。
  • 怀疑者则质疑其长期可行性、二进制体积、某些缺失特性（集群、丰富的 GUI/生态、CSS 工具链），以及是否真的需要另一个 JS 运行时/注册表。