比较node.js和Deno

前言

如果你一直关注 web 开发领域，那么最近可能已经听到了很多关于 deno 的信息——一种新的javascript运行时，它可能也会被认为是 node.js的继承者。但是这意味着什么，我们需要“下一个 node.js” 吗？

什么是 deno？

要了解发生了什么，我们首先需要看一下 deno 到底是什么。就像我前面说过的那样，这是一个新的javascript运行时，也就是要执行 js代码的环境。它最初是由ryan dahl创造的，他在之前曾经为我们把 deno 与node.js进行了比较。

ryan在jsconf eu 2018 演讲上宣布了 deno，标题为“node.js 的十大遗憾”。仅从那条信息中，你就可以知道进展情况。 deno 是从头开始创建的，是当前对 node.js 的更好的实现。

但是 node.js 有什么不好的地方？deno 如何与它更成熟的表兄抗衡？

与 node.js 的比较

尽管 deno 和 node.js 是执行相似操作的类似工具，但它们之间的差异远远不只是名称的颠倒。

体系结构

让我们先来了解一下 deno 的内部原理。就像 node.js 一样，它基于 chromium 的v8javascript 引擎，并使用事件驱动，非阻塞架构。但是两者的主要编写语言有所不同。node.js 主要使用c ++编写，libuv作为其异步 i/o 库，而 deno 用的是rust，同样其使用的异步库tokio也是用 rust 编写。

对于这些差异如何转化为实际性能，我们必须拭目以待。就目前而言，根据deno 的基准，两者之间的区别是无法区分的，或者说至少是非常微妙的。

es模块

你可能知道，node.js 当前的模块系统是所谓的commonjs（带有require()的那个），尽管esm（ ecmascript 模块（带有import和export的模块）成为 js 的官方标准已有相当长的一段时间了，可以追溯到2015 年推出的es6。当然，node.js 确实支持 esm，但是此功能目前（[ v14.xx） 被标记为实验性的，从而迫使 js 社区仍然使用 commonjs 模块系统 或其他打包器。

这就是 deno 要推出的东西，它仅支持 esm 模块 —— 一个真正的模块系统！

依赖管理

但是，除了 esm 之外，deno 还为 node.js 带来的依赖性管理带来了更多变化。

基于从有着上百万个包的npmregistry和类似黑洞的node_modules目录中汲取的经验，deno 采用了一种完全不同的依赖关系方法。 deno 不需要类似npm的 registry 和包管理器，而是直接从 url 导入并使用依赖项：

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
    req.respond({ body: "hello world\n" });
}

然后将下载的模块不可见地存储在计算机上的某个位置。是的，这意味着不会再有node_modules！

可是等等！还有更多...或者我应该少说，因为 deno 还摆脱了现在制作的万能的package.json文件。除了deps.ts文件之外没有其他的替代选择，它的作用更像是所有外部模块的重定向排序文件：

export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";

至于 npm registry，因为 deno 现在可以从 url 加载依赖项，所以这与 node.js 的要求不一样。但是如果你对这个选项感兴趣，deno 会提供自己的包托管。

typescript 和其他功能

是的，你已经看到了 ——javascript 是使用 deno 的主要语言，另外还支持typescript，。该支持是内置的，不需要类似custom registers的东西或复杂的设置。

但是，除了 ts 支持之外，deno 还内置了许多其他有用的工具。它们当中的大多数以命令形式出现，例如fmt、bundle或doc，分别提供代码格式化，打包和文档生成等功能。

api

至于 api，deno 肯定是自己的东西。一切都是用 typescript 编写的，异步 api 仅基于promise。核心功能被限制在最低限度，而其他所有功能都可以在标准库中找到。

所以从表面上看，这一切看起来都很好，而且非常有前途，但是当你意识到更改所有的 api 意味着将 node.js 代码库转换为 deno 更加困难时，这种愉悦的心情立即消失了。可悲的是，所有新的和更好的东西都必须付出代价，对吗？

安全

最后，安全性是 deno 最重要的方面之一。与 node.js 相比，它用沙盒执行的代码，仅允许访问系统的选定部分。这意味着通过传递适当的标志，可以轻松地限制对磁盘、网络和子进程等内容的访问。

那么，这意味着什么？

因此，我刚刚以非常简短的方式向你介绍了 deno 的一些功能，以便你能够掌握所有内容的要点。你可以根据需要进行更深入的研究（我将在本文结尾放一些不错的文章链接）。

让我们回过头来讨论这个博客文章的主要问题——这意味着什么？好吧，主要是因为deno v1已经在2020 年 5 月 13 日发布（正好是其首次发布的第二年）。现在每个人都在问这是否将会成为“下一个大事件”，或者它是否将会完全取代 node.js。

就个人而言，我认为现在讨论这些还为时过早。考虑到项目的规模和社区的期望，该项目尽管已经是 v1 版了，但要成为可行的 node.js 替代者还有很长的路要走。请记住，这些技术（即使存在所有差异）仍然要做同样的事情，同时必须相互竞争。而且 node.js 的开发也不会过时（例如基于 promise 的 fs api变体或 esm 实验性支持），这意味着我们很可能会在这个存在两个 javascript 运行时的世界中生活很长时间（说的好像对 js 开发人员来说是个新鲜事一样）。并且请记住，我甚至没有提到庞大的 npm registry 和生态系统，尽管它们无论如何都不是完美的，但仍然为 node.js 增添了很多价值——这是 deno 目前还不具备的优势。

底线

总而言之，node.js 不会出现在任何地方，并且，如果你要启动一个用于生产的严肃项目，那么至少就目前而言，最好还是坚持使用 node.js。话虽如此，但是没有什么人（当然不是我）或事情能够阻止你去使用 deno，甚至把 deno 用于严肃的项目。看起来它确实像是未来，但是我们根本还没有到达。

以上就是比较node.js和deno的详细内容，更多关于node.js和deno的资料请关注其它相关文章！