Deno 稳定版本大约在 3-4 年前推出。当时，它受到了相当多的关注，因为 Node.js 的创建者 Ryan Dahl 也是 Deno 的赞助人。哈！你没听错。他为什么要创造一个新工具来和自己的“孩子”竞争？
Ryan Dahl 承认 Node.js 存在严重弱点。最初，Node.js 的设计重点是简单性和灵活性。但这些年来，一切都已经超出了控制。 Node.js 已经发展得非常强大，获得了更多的关注，当人们试图将所有东西都打包到这个后起之秀中时，它变得不必要的复杂。
Deno 的诞生就是为了解决 Node 的弱点。然而，在推出之时，它并没有展现出自己的优势。它的性能甚至不如 Node.js，更不用说缺乏 npm 支持——这是 Node 最大的优势之一。这让事情变得越来越困难。
作为一个好奇的人，我很快使用 Deno 尝试了一些代码片段，并意识到图书馆系统的不便。 “哇，我最喜欢的图书馆可能需要很长时间才能出现在这个平台上；一切看起来既新又陌生，”我想！
当我开始“拆除并重建”我的博客时，一切都改变了。经过多次对技术选择的犹豫和思考，Fresh这个名字出现了。然而，Fresh 需要 Deno 作为其运行环境。之前没有部署经验，但认为“这只是一个 JavaScript 运行时环境！”给了我更多的信心。下一个故事就是这篇文章。
今天，我总结一下在使用 Deno 时我感觉“喜欢”的 5 点。
Deno 原生支持 TypeScript。这意味着您可以直接运行 .ts 文件，而无需像其他库通常那样执行到 .js 的转换步骤。很多人想知道这和使用 ts-node 这样的工具来运行 TypeScript 代码有什么不同吗？答案肯定是肯定的，因为 ts-node 需要 TypeScript 配置文件才能在复杂的情况下工作，而 Deno 则不需要。默认支持 TypeScript，简化了直接运行 .ts 代码的过程。
我经常创建脚本来为自己处理一些小任务。每次创建新脚本时，我总是在选择 .js 还是 .ts 之间犹豫。当 Deno 出现时，.ts 成为默认选择。即使在 Node 项目中，当我需要编写脚本来执行快速任务时，我仍然更喜欢选择 .ts 并使用 Deno 来执行该代码。
随着我越来越多地参与 JavaScript/TypeScript 项目，尤其是 Node.js，我一直想知道甚至觉得烦人的一件事是……配置文件太多了。每个不同的项目都有不同名称的文件。如果项目使用 Typescript，则来自 package.json、package-lock.js 和额外的 tsconfig.js...更不用说我是否需要配置更多东西，如 webpack、vite、tailwind、postcss...天哪！一开始，由于不熟悉，我不得不通过阅读来了解项目中出现的每个配置文件的意义和用法，边读边默默咒骂“你到底是怎么能创建数百个这样的配置文件的？”
当迁移到 Deno 时，我惊讶地发现根本没有配置文件。这意味着您可以在没有任何配置的情况下运行该项目 - 听起来很超现实，对吧？如果有的话，它也只是一个 deno.json 文件。 Deno 巧妙地消除了许多复杂的配置或将它们放入单个 json 文件中。打开一个项目真是一种解脱，不用再担心出现奇怪的名字了！
Deno 一直并且正在尝试尽可能多地支持 Web API。 Web API 是浏览器中可用的一组标准化 API。对 Web API 的良好支持可以允许在 Deno 中运行的程序也可以在浏览器中运行，遵循一次编写 - 随处运行的范例。这为“通用”图书馆开辟了途径。
如果您曾经使用过 Serverless，尤其是 Cloudflare Workers，您就会知道 Workers 与 Node.js 并不完全兼容，因此使用 Node 特定的库可能不起作用。另一方面，如果一个库使用 Web API 或与 Web API 兼容，那么它运行起来会很顺利。这也适用于 Deno。
对 Node API 的支持允许 Deno 在 npm 上运行大多数“包”。这样，你就可以自由地使用 npm 包而不必再担心兼容性了。
很奇怪的是，有一个明显的事实是，当启动一个 Node 项目时，它会默认拥有所有用户的权限。这意味着程序可以代表用户自由访问文件或执行系统中的命令。相当危险，不是吗？想象一下，如果你不小心“运行”了别人的项目，而没有先检查它，它会扫描你机器上的所有数据，将其发送回某个服务器，或者加密所有文件以勒索赎金，那么你的生活就毁了，这是一个无法弥补的错误已更正！
Deno 通过在运行应用程序时添加请求权限的标志来解决此缺陷。权限可以包括文件访问、互联网访问……如果程序想要访问文件系统或连接互联网，它至少必须请求权限。例如：
$ deno run --allow-read --allow-write --allow-net index.ts
有很多权限需要“请求”；有关更多详细信息，请参阅安全和权限 |德诺文档。最快的方法是使用 -A 或 --allow-all 标志来允许所有权限。
我记得它刚推出的时候； Deno 在程序性能方面似乎落后于 Node.js。具体来说，基准测试显示了运行相同程序时 Deno 和 Node 之间的差异；德诺总是表现不佳。有一次，bun.sh突然出现了。 Bun 之所以成为一种现象，是因为它在性能方面优于 Node.js。这让 Deno 显得更加呆板。
实际上，在使用bun运行一些Node应用程序时，我遇到了很多问题甚至bug。看来包子还没有准备好“生产”。所以当时我的结论是，对于那些热爱稳定的人来说，Node 仍然是首选。
最近，随着 Deno 2.0 的发布，我们在性能提升和增强这只“黑色恐龙”的编程体验方面做出了巨大的努力。根据他们发布的最新文档，与众所周知的 Node 和 Bun 相比，Deno 在各个方面都脱颖而出。
以上是我在使用 Deno 时喜欢的点。还有一些功能，例如免费提供 Deno Deploy 来部署应用程序。然而，我仍然偶尔会看到一些文章“批评”性能和模块系统，以及与 Node.js 的低兼容性。这些限制已在最新的 2.0 版本中得到解决。我对 Deno 的看法与刚推出时相比有所改变，希望 Deno 未来能得到社区更多的关注，取得更多的突破。
你呢？你用过德诺吗？您对这个 JavaScript 运行环境有什么赞扬或批评吗？请在下方留下您的评论！
以上是我喜欢 Deno的详细内容。更多信息请关注PHP中文网其他相关文章！
