Deno 并不是下一代 Node.js

这几天前端圈最火的事件莫过于 ry(Ryan Dahl) 的新项目 deno 了，很多 IT 新闻和媒体都用了标题：“下一代 Node.js”。

0. 为什么开发 Deno？

这是我上周做的一张图，介绍了 JavaScript 的发展简史。刚才修改了一下，添加了对 Node.js 和 Deno 发布时间的标注。

Node.js 和 Deno 分别是 Ryan Dahl 在 2009 年和 2018 年，基于当年最新的前端技术开发的非浏览器 JavaScript 运行时。

JavaScript 历史（Node & Deno）

Ryan Dahl 开发 deno 并不是因为 “just for fun”，也不是为了取代 node。下面慢慢解释。

1. 目前 deno 只是一个 demo

这两天花时间看了 deno 的源码（好在是初级阶段，源码很少，也很容易理解），顺带看了所有的 issue 和 pr。不知道“从官方介绍来看，可以认为它是下一代 Node”是如何脑补出来的。

既然是 Node.js 之父的新作，在讨论中自然离不开 Node.js。而作者很皮的回复到：

The main difference is that Node works and Deno does not work : )最大的区别就是：Node 可以工作，而 Deno 不行 : )

目前 Deno 只是一个 Demo，甚至连二进制发行版都没有。好在从源码编译比较简单（如果你使用的不是 Windows 系统）。

在 high-level 层面，Deno 提供了一个尽可能简单的 V8 到系统 API 的绑定。为什么使用 Golang 替代 C++ 呢，因为相比 Node 而言，Golang 让我们更加容易的添加新特性，比如 http2 等。

至于为什么不选择 Rust，作者没有回答。

我们再对比一下两者的启动性能。分别运行：

console.log('Hello world')

node vs deno

我之前写过一篇文章：Node.js 新计划：使用 V8 snapshot 将启动速度提升 8 倍，那如果我们使用 --without-snapshot 参数编译 Node.js 呢？

deno vs node(without-snapshot)

依然是相差悬殊，毕竟 deno 需要加载一个 TypeScript 编译器。毕竟是一个 demo 版本，希望以后用力优化。

对于性能提升还有一个思路就是，可以使用 LLVM 作为后端编译器把 TypeScript 代码编译为 WebAssembly 然后在 V8 里面运行，甚至可以直接把源码编译成二进制代码运行。Ryan Dahl 表示 deno 只需要一个编译器，那就是 TS。但是既然 deno 要兼容浏览器，那么 WebAssembly 应该也会被支持。

Deno 可以对 ts 的编译结果进行缓存（~/.deno/cache），所以目前关注的就是启动速度和初次编译速度。

要么就是在发布前先行编译，如此一来 deno 就脱离了开发的初衷了。deno 是一个 ts 的运行时，那么就应该可以直接运行 ts 代码，如果提前把 ts 编译成 js，那么 deno 就回退到 js 运行时了。

2. 初学者应该学习 Node.js 还是 Deno？

对于这个问题，Ryan Dahl 的回答干净利落：

Use Node. Deno is a prototype / experiment.使用 Node。Deno 只是一个原型或实验性产品。

从介绍可以看到，Deno 的目标是不兼容 Node，而是兼容浏览器。

所以，Deno 不是要取代 Node.js，也不是下一代 Node.js，也不是要放弃 npm 重建 Node 生态。deno 的目前是要拥抱浏览器生态。

不得不说这个目标真伟大。Ryan Dahl 开发了 Node.js，社区构建出了整个 npm 生态。我在另一个回答 justjavac：纯前端开发眼里nodejs到底是什么？ 里面写到“Node.js 是前端工程化的重要支柱之一”。

虽然后来 Ryan Dahl 离开 Node.js 去了 Golang 社区，但是现在 Ryan Dahl 又回来了，为 JavaScript 社区带来了 Golang，开发出了 Deno，然后拥抱浏览器生态。