2026年10月他终于爬回节点（Node.js），在SvelteKit（SvelteKit）客户项目上重度使用节点，惊讶其变得这么好。Deno（Deno）长期是首选运行时，他忘了怎么用节点。如今回来发现ECMAScript（ECMAScript）语法糖全支持，老旧API被替换或现代化，最重要的是不必看到require()。包管理方面，官方文档推荐用脚本安装NVM（NVM）管理节点和NPM，他过往体验不佳，听说快速节点管理器（FNM）切换版本更好。他选择PNPM（PNPM）以避免安全问题，并设置了别名。
正文
我终于得爬回 Node 了！这个月在一个 SvelteKit 客户项目上大量使用 Node，它什么时候变得这么好了？我长期把 Deno 当主力运行时，都忘了怎么用 Node。回来后发现 ECMAScript 语法糖都支持了，老的烦人 API 也被替换或现代化，最重要的是再也不用看 require()。
包管理
官方 Node 文档建议用管道把网络脚本直接喂给 bash 来装 NVM 管理 Node 和 NPM（我们从不吸取教训）。我以前用 NVM 和 NPM 体验并不好，听说 FNM 切换版本更好，但我既要尝鲜又要兼顾客户项目的稳定性。
为了避免立刻被黑，我选了 PNPM（NPM 里的 M 代表 malware）。有些脚本硬编码了二进制名，我加了别名：alias npm=pnpm 和 alias npx=pnpx。可能算离谱但很好用。PNPM 还会拦掉 post-install 脚本。
我在 pnpm-workspace.yaml 加了设置延迟恶意更新：minimumReleaseAge: 1440 和 trustPolicy: no-downgrade。起初我设成“一个月”，因为微软至少那么久才删举报的恶意包，但导致依赖匹配困难，后来改成“一天”，足够让别人先当小白鼠。
TypeScript
Node 现在能直接跑 TypeScript 了，但不能直接发 TS 包到 NPM，会报 ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING 错误。Node 故意拒绝处理 node_modules 里的 TS 文件，是为了阻拦作者发布 TS 包，这是哲学而非技术限制。我理解，TS 是微软产品，开口子会污染生态。我希望 ECMAScript 有轻量原生类型提案，但估计退休前都看不到。
没有 TS 包意味着我得找打包工具，Tsdown 搞定了，只多两个配置文件，删掉 deno.json 之类算扯平。
因为微软搞砸了 GitHub，我自建了 Forgejo 实例。NPM 的限制让我的包丢了 provenance 凭证，我得配置 PNPM 信任策略来允许自己的包。
迁移我的网站
最后测试是把静态站点生成器从 Deno 转过来。之前的 Node 版本还得大改，现在用 Node v26.10.0 发现改动极少：只需把 Deno 文件系统 API 换成大幅改进的 node:fs，Deno.serve 换成 Hono 的 node 适配器（包了 node:http）。之后把 @std/path 换成 node:path。
迁移后震惊地发现构建速度快了 15%。代码还是 Deno 风格，应该还有性能可挖。Node 确实焕然一新！你也许早知道了，我纯属习惯用 Deno。
Deno 的衰落
Deno 让硅谷马戏团定义“成功”，从创新运行时变成无聊创业公司，裁掉一半人，剩下发 AI 幻想。现在没理由用 Deno 运行时了，公司早不创新，Node 已追上甚至超越。
最终推我走的是：
- ZSH 集成坏了几周
- JSR 的激进“429 (Too Many Requests)”
- 让 Deno 并发 HTTP 请求噎住的 bug
JSR 支持很快删了我的账号。早期好玩，现在告别，brew uninstall deno。
评论
社区对 Deno 态度分裂，既有人赞赏其一体化的开发体验，也有人批评其专有 API 造成生态隔离并正逐渐边缘化；多数人将 Node 看作稳定终极选择，少数用户偏好 Bun 却指出其兼容硬伤，而 LLM 普及被认为削弱了传统 JS 运行时的必要性。
认为 Node 是稳妥且终将胜出的运行时
- 认为 Node 优秀且持续交付稳定性，其他运行时最终会被它吸收，选择它最安全（较多人）。 > Node 真的很好，它之外的东西最终都会被吞没，Node 是安全赌注（@moralestapia）
认为 Deno 的内置工具链让开发和发布 TypeScript 更简便
- 赞赏 Deno 自带测试、lint、类型检查及 JSR 发布 TypeScript 库的简便，避免了 Node 项目繁琐配置（较多人）。 > 我仍轻易选 Deno，因为内置测试、lint 和类型检查，我看重这种简单性（@AgentME）
认为 Deno 的专有 API 造成生态分裂且存在兼容缺陷
- 指出 Deno 自有 API 迫使应用写成“Deno 应用”，形成孤立生态；直接运行 TypeScript 缺失、子进程 OpenSSL 问题也降低吸引力（较多人）。 > 若用 Deno 自有 API 就得把应用写成“Deno 应用”，制造了两个不同的生态系统（@chrysoprace）
认为 Deno 正面临衰落且错失 LLM 时代机遇
- 担忧 Deno 裁员后缺乏路线图与沟通，逐渐边缘化；LLM 盛行下少被选用进一步打击其前景（较多人）。 > 裁员后似乎没有路线图和沟通，我好奇他们去向何方（@isyouaint）
认为 Bun 的使用体验优于 Node 和 Deno
- 尽管经历被收购和 Rust 重写风波，有用户认为在多项维度上 Bun 比 Node 或 Deno 更好（少数人）。 > 尽管现在因收购和重写争议不受宠，我在文章各维度上更喜欢 Bun（@fastball）
认为 Bun 的 Node 兼容宣称被 HTTP GET 限制打破
- 指出 Bun 若不支持 GET 请求带请求体，会导致 Elasticsearch 等真实工具失效，作为 Node 替代却存在破坏性变更不可取（少数人）。 > 宣称与 Node 兼容却有此破坏性变更，希望尽快修复（@elendilm）
认为 Node 禁止直接运行 TypeScript 是配置匹配问题而非反微软
- 澄清 Node 禁用直接执行 TypeScript 并非出于对微软的排斥，而是不同项目 TSConfig 不匹配会导致库内类型错误；用声明文件即可解决（较多人）。 > Node 禁止此行为无关微软，而是因你拉取的库与你项目的 TS 配置可能不一致（@Naitronbomb）
认为 LLM 兴起削弱了单一运行时与语言的价值
- 认为随着 LLM 辅助，人们按环境选专用技术栈，用英语作为共享语言，传统 JS 运行时必要性降低；Deno 不被 LLM 默认采用雪上加霜（较多人）。 > 我们的共享语言现在是英语，横跨测试、前后端和产品，语言本身不再重要（@seer）
有价值的补充
- 微软早在 2020 年便通过 GitHub 收购了 npm，文中将 TypeScript 视为外部污染的说法与 Node 限制的真实原因脱节。
- TypeScript 编译器自带的声明文件机制已能解决向 npm 发布 TypeScript 包的需求，无需强制打包，且不妨碍纯 JS 用户使用。
- 有开发者观察到，借助 LLM 以严格 lint 规则“氛围编程”产出的多语言代码库，在特定环境下比统一用 Node 写的精细代码表现更优。