这篇文章主要介绍了node.js和Deno有什么区别，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
要了解发生了什么，我们首先需要看一下 Deno 到底是什么。就像我前面说过的那样，这是一个新的JavaScript运行时，也就是要执行 JS代码的环境。它最初是由Ryan Dahl创造的，他在之前曾经为我们把 Deno 与Node.js进行了比较。
Ryan在JSConf EU 2018 演讲上宣布了 Deno，标题为“Node.js 的十大遗憾”。仅从那条信息中，你就可以知道进展情况。 Deno 是从头开始创建的，是当前对 Node.js 的更好的实现。
但是 Node.js 有什么不好的地方？Deno 如何与它更成熟的表兄抗衡？
尽管 Deno 和 Node.js 是执行相似操作的类似工具，但它们之间的差异远远不只是名称的颠倒。
让我们先来了解一下 Deno 的内部原理。就像 Node.js 一样，它基于 Chromium 的V8JavaScript 引擎，并使用事件驱动，非阻塞架构。但是两者的主要编写语言有所不同。Node.js 主要使用C ++编写，libuv作为其异步 I/O 库，而 Deno 用的是Rust，同样其使用的异步库Tokio也是用 Rust 编写。
对于这些差异如何转化为实际性能，我们必须拭目以待。就目前而言，根据Deno 的基准，两者之间的区别是无法区分的，或者说至少是非常微妙的。
你可能知道，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 会提供自己的包托管。
是的，你已经看到了 ——JavaScript 是使用 Deno 的主要语言，另外还支持TypeScript，。该支持是内置的，不需要类似custom registers的东西或复杂的设置。
但是，除了 TS 支持之外，Deno 还内置了许多其他有用的工具。它们当中的大多数以命令形式出现，例如fmt、bundle或doc，分别提供代码格式化，打包和文档生成等功能。
至于 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有什么区别”这篇文章对大家有帮助，同时也希望大家多多支持亿速云，关注亿速云行业资讯频道，更多相关知识等着你来学习!
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
