Deno 并不是下一代 Node.js

这几天前端圈最火的事件莫过于 ry(Ryan Dahl) 的新项目 deno 了,很多 IT 新闻和媒体都用了标题:“下一代 Node.js”。这周末读了一遍 deno 的源码,特意写了这篇文章。长文预警(5000字,11图)。

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,然后拥抱浏览器生态。

猜你喜欢

转载自blog.csdn.net/qq_32778043/article/details/80860400