Deno需要做什么才能取代Node.js？

本文转载自公众号“读芯术”(ID：AI_Discovery)。

Deno是一个Javascript/TypeScript的运行时，旨在取代Node.js的地位。它拥有广泛功能，讨论度非常高，在Github上有将近68000个星星：

既然这么受欢迎，那么有人要问了：为什么Deno正式版本1.0发行时没能成功呢?本文就将深入探讨这个问题。

什么是Deno

Deno是由Ryan Dahl(也是Node.js的原创者)创建的安全的JavaScript和TypeScript运行时，它的创建是为了弥补2009年首次设计Node.js时的疏忽。这种出发点很有意义，我敢肯定每个程序员都希望有机会重写他们10年前的代码。

因此，Deno在Node.js基础上新增了很多特征，以下是其中一些：

• Deno默认设定就是安全的。必须通过选择才能访问文件系统、网络或环境。
• Deno为TypeScript的延伸。
• 外部文件由URL明确引用，没有package.json。
• 导入语句包括扩展名为.ts，.tsx，.js，.json的文件。
• 内置的依赖项检查器和文件格式化工具。

凭借这些功能以及大量的开发者炒作，Deno于2020年5月正式发布了1.0版。接着……它扑街了。

为什么Deno没有成功?

图源：unsplash

Deno似乎拥有致胜的所有要素。它追随者众多，功能多样扎实，创作者经验老道等等，但结果却未能达到人们的期望。这是为什么?

我认为最好从商业角度揭秘。很多人都忽略了一点：构建开源软件与为用户构建软件实在没有什么不同。基本的经济原则——供求关系，仍然发挥着重要作用。当有人创建一个新的开源项目时，他们势必要与已建立的平台竞争。鉴于此，不仅要考虑新项目的优越性，还必须与现有项目作比较。

对Deno来说，现有的是Node.js，尽管Node.js可能有所不足，但它仍能出色完成任务。如若Deno推出了Node.js无法复制的强大特征，就可能会改变游戏规则。但Deno没有。

从用户的角度来看，Deno具有的只是“次要特征”。它具有更简洁的代码库，使用了最新最佳的经验，更加安全，但是这些东西对用户来说仅是“特性”，并非产品自身。

你可以做一个像Gmail一样的电子邮件客户端，它应更加安全并提速50%，可是用户仍然不会转而使用它，即使重新创建书签用时不多，人们也觉得不值得。Deno第一击未中：它具有许多不错的特征，但是没有什么能让用户放弃Node.js的杰出之处。

Deno的另一个主要失败之处是它不支持NPM软件包。如果Deno能够支持NPM软件包，就很可能能够改变形势。Deno支持NPM软件包将使它们不再像“单独的电子邮件客户端”，更像是对当前客户端的更好包装。支持NPM软件包将大大降低进入壁垒。这将为用户把项目和库迁移至Deno提供一个良好的铺垫。

这类似于TypeScript的“严格模式”。对于具有JavaScript强大代码库的用户，直接转用TypeScript会降低你几周内梳理错误消息的效率。

由于TypeScript可以取消严格模式，于是它可以为用户完全转向使用TypeScript做铺垫。这使它们的进入门槛大幅降低，又助力TypeScript争得近年来JavaScript抢占的市场份额。

启示是什么?

图源：unsplash

笔者认为这是一个有趣的案例，例证了更多的商业方法。给我们带来的启示就是，如果你要发布新产品，请务必确保它具有强大的优点，能够克服人们拒绝转变现状的阻力。

Deno具有魅力，但归根到底，只是多了一系列的小“修复”，代价却是失去了Node.js培育的整个NPM生态系统(也曾助它们壮大)。

那么，Deno接下来何去何从?首先他们得做出决定。要么努力增加Node.js库的向后兼容性，要么提供更多好处来诱使用户转换平台。笔者认为更应拓展向后兼容，此后将极大改善项目的未来。