有开发者写了篇文章，讲自己 2021 年对 Deno 感觉良好，现在又回到 Node，并且对 Node 的进步幅度感到意外。他把站点生成器移植回来，改动很少。
这类回归文章的价值
技术选型的真实反馈往往出现在「用了一段时间之后」和「换回来之后」这两个时间点。前一种容易带着新鲜感，后一种通常更冷静。
文章里提到的一个细节很有说服力：移植成本比预期低。这说明两边的 API 差异没有想象中大，也说明 Node 这几年补齐了不少能力。
Node 补了什么
TypeScript 支持、内置测试运行器、原生 fetch、权限模型的部分探索、以及性能上的持续改进。
这些改动单独看都不惊艳，但叠加起来改变了日常体验：以前要装一堆依赖才能开工，现在脚手架可以更薄。
Deno 的问题出在哪
作者没有回避这一点。Deno 的定位一直是「修正 Node 的历史问题」，但这个价值主张随着 Node 自己改进而弱化。
当一个替代品的优势被原品追上时，用户留下来的理由就只剩生态之外的东西——而生态恰恰是 Node 的强项。
什么时候选 Deno 仍然合理
新项目、团队规模小、对默认安全模型有强需求、或者本来就想用更现代的 Web 标准 API，这些场景下 Deno 仍有吸引力。
一个选型原则
运行时的选择应该跟着约束走，而不是跟着喜好走。真正的约束通常来自：要用的库在哪个生态、部署平台支持什么、团队熟悉什么。
如果三个答案不一致，优先级从上到下。库的可用性是最刚性的约束——没有生态，写什么都得自己造。
对观望者的建议
别急着换。运行时的迁移成本在中后期项目里非常高，收益却往往来自开发体验这类软指标。
如果确实想评估，用一个小项目跑完整生命周期——从初始化到构建到部署到监控。只跑 hello world 得不出结论。
顺带一提
这类技术回归的文章在社区里常被当成站队，其实更有价值的读法是看它列出的具体问题。哪些是真的痛点，哪些只是不习惯，区分清楚比结论重要。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。