问题
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 点。
typescript 支持
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 文件中。打开一个项目真是一种解脱，不用再担心出现奇怪的名字了！
支持 web api 和 node api
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 运行环境有什么赞扬或批评吗？请在下方留下您的评论！
