本文主要是介绍Deno来了!，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前言

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

什么是 Deno？

要了解发生了什么，我们首先需要看一下 Deno 到底是什么。就像我前面说过的那样，这是一个新的 JavaScript 运行时，也就是要执行 JS 代码的环境。它最初是由 Ryan Dahl 创造的，他在之前曾经为我们把 Deno 与 Node.js(https://nodejs.org/) 进行了比较。

Ryan在 JSConf EU 2018 演讲(https://youtu.be/M3BM9TB-8yA) 上宣布了 Deno，标题为 “Node.js 的十大遗憾”。仅从那条信息中，你就可以知道进展情况。Deno 是从头开始创建的，是当前对 Node.js 的更好的实现。

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

与 Node.js 的比较

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

体系结构

让我们先来了解一下 Deno 的内部原理。就像 Node.js 一样，它基于Chromium 的 V8 (https://v8.dev/) JavaScript 引擎，并使用事件驱动，非阻塞架构。但是两者的主要编写语言有所不同。Node.js 主要使用C ++编写，libuv (https://github.com/libuv/libuv)作为其异步 I/O 库，而 Deno 用的是 Rust，同样其使用的异步库 Tokio(https://tokio.rs/)也是用 Rust 编写。

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

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 带来的依赖性管理带来了更多变化。

基于从有着上百万个包的 NPM registry 和类似黑洞的 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 { 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 (github.com/TypeStrong/…) 的东西或复杂的设置。

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

API

至于API，Deno肯定是自己的东西。一切都是用TypeScript 编写的，异步 API 仅基于 Promise。核心功能被限制在最低限度，而其他所有功能都可以在标准库 (https://deno.land/std) 中找到。

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

安全

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

那么，这意味着什么？

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

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

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

底线

那么至少就目前而言，最好还是坚持使用 Node.js。话虽如此，但是没有什么人（当然不是我）或事情能够阻止你去使用 Deno，甚至把 Deno 用于严肃的项目。看起来它确实像是未来，但是我们根本还没有到达。

Deno 资料:

• Deno 1.0
• The Deno Handbook: a concise introduction to Deno 🦕
• Deno 1.0: What you need to know
• 🎉 Deno: 1.0 officially scheduled on May, 13! Review of the features

原文链接：areknawo.com/deno-why-al…

这篇关于Deno来了!的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！