node deno_为什么我相信Deno是JavaScript运行时环境朝错误方向迈出的一步

node deno

I haven't found any other developers on YouTube with a channel the size of codedamn (100K+ subscribers) who are not not "super excited" about the release of Deno.

我还没有在YouTube上找到其他开发者，他们的频道大小达到了该死的人数 (超过10 万名订阅者)，他们对Deno的发布并不感到“超级兴奋”。

Last week, I released a video on my channel stating some reasons (that were pretty clear to me) why I believe we do not need Deno - another runtime environment for JavaScript built on the top of V8 and Node.

上周，我在自己的频道上发布了一段视频，阐明了一些我认为我们不需要Deno的原因(我很清楚)，Deno是另一个基于V8和NodeJavaScript运行时环境。

With an article like this, I can add more thoughts and bundle them in a better way than a video. But anyway, if you're interested, here's what I posted:

通过这样的文章，我可以添加更多的想法，并以比视频更好的方式将它们捆绑在一起。 但是无论如何，如果您有兴趣，这是我发布的内容：

To just prove that I'm not against "Deno" and JavaScript in general, I'd like to state something. I love JavaScript more than anything. My primary tech stack involves nothing but JavaScript - Node / React / MongoDB / React Native / NativeScript / Ionic / you name it.

为了证明我总体上不反对“ Deno”和JavaScript，我想说明一下。 我最喜欢JavaScript。 我的主要技术栈只涉及JavaScript，即Node-React / MongoDB / React Native / NativeScript / Ionic /您自己命名。

I built a 100K subscriber YouTube channel and a developer platform mostly on a single programming language - JavaScript.

我主要使用一种编程语言-JavaScript构建了10 万个订户YouTube频道和一个开发者平台 。

But at the same time, it's important to stay practical and keep a clear head to see both sides of the coin. Deno has a good side, as well as a side which people aren't seeing/writing about yet. I'm going to write my views on the second side. Let's go!

但同时，重要的是要保持实用性，并保持头脑清醒，以观察硬币的两面。 Deno具有良好的一面，以及人们尚未看到/书写的一面。 我将在第二面写我的观点。 我们走吧！

Note: This is going to be a controversial article. Let's keep it civil and control our emotions. I'd love it if you'd read the full article till the end, and maybe then decide what you think. I have my social media links at the bottom of the article and would love to have a healthy discussion on this topic there.

注意：这将是一个有争议的文章。 让我们保持礼貌，控制自己的情绪。 如果您能阅读全文直至结尾，然后决定您的想法，我将非常喜欢。 我在文章底部有我的社交媒体链接，并希望在那里就此主题进行健康的讨论。

Deno vs Node-实际上存在竞争 (Deno vs Node - there IS actually competition)

A lot of people in the industry are saying "oh well, there isn't any competition between Deno and Node, there is a lot both can learn from each other".

行业中很多人都在说：“哦，Deno和Node之间没有任何竞争，彼此之间可以学到很多东西”。

To some extent, I agree, there's a lot Node and Deno can learn from each other. But there's no competition? I completely disagree with that.

在某种程度上，我同意，Node和Deno可以互相学习很多。 但是没有竞争吗？ 我完全不同意这一点。

Let's look at common features of Deno and Node:

让我们看一下Deno和Node的共同特征：

1. They're both runtime environments for JavaScript
   它们都是JavaScript的运行时环境
2. They both run on any computer where you can run V8
   它们都可以在可以运行V8的任何计算机上运行
3. They both have ECMAScript standard support
   他们都有ECMAScript标准支持
4. They're both actively maintained
   他们都积极维护

If you become a "Deno" fan 2 years down the road, you are never going to choose Node for your next project. It's just not possible.

如果您成为未来两年的“ Deno”粉丝，那么您永远不会为下一个项目选择Node。 只是不可能。

Similarly, if you've never worked with TypeScript before, and you think you want to try Deno, but maybe you want to have some NPM modules, you wouldn't choose Deno.

同样，如果您以前从未使用过TypeScript，并且认为自己想尝试Deno，但也许想要拥有一些NPM模块，则不会选择Deno。

That's right: there is a division of developers across Deno and Node - I would say that's a very good example of a competitive space.

没错：Deno和Node的开发人员之间存在分歧-我想说这是竞争空间的一个很好的例子。

为什么要尝试Deno？ (Why try Deno?)

Firstly, I would like to list some advantages of Deno – what it is and why it pitches itself as a better runtime:

首先，我想列举一下Deno的一些优势–它是什么以及为什么它将自己推销为更好的运行时：

1. It overcomes some shortcomings of Node
   它克服了Node的一些缺点
2. It's a secure runtime environment by default
   默认情况下这是一个安全的运行时环境
3. It has TypeScript support baked in
   它具有TypeScript支持
4. It uses promises all the way down
   它一直使用诺言
5. It's built on Rust (vs C++ for Node)
   它基于Rust构建(与Node的C ++相比)

In the next section, I'll pick all of these points apart one by one and will mention what Node can learn from them. I'll also discuss, wherever necessary, why Deno doesn't make a lot of sense.

在下一节中，我将一个接一个地挑选所有这些要点，并提及Node可以从中学到什么。 我还将在必要时讨论Deno为什么没有多大意义。

迪诺在哪里过分？ (Where Deno overdid?)

Let's pick up the USPs of Deno and break them down one by one:

让我们拿起Deno的USP并将它们一一分解：

默认情况下安全的运行时环境 (Secure runtime environment by default)

This is the most celebrated feature of Deno, and I'm surprised by it. Deno runs your JavaScript code in a secure sandbox by default - preventing access to file system and network unless you explicitly opt-in.

这是Deno最著名的功能，我对此感到惊讶。 Deno默认情况下在安全的沙箱中运行JavaScript代码-除非您明确选择加入，否则禁止访问文件系统和网络。

Deno does this because it wants to mimic the browser. But why? Why would you want to mimic the browser in the first place? Deno abides by the ECMAScript standard, which is great! But what's with the crazy love of browsers?

Deno这样做是因为它想模仿浏览器。 但为什么？ 您为什么首先要模仿浏览器？ Deno遵守ECMAScript标准，这太棒了！ 但是对浏览器的狂热是怎么回事？

I get it, you want to maintain compatibility between the code written on clients and servers. But it has been so strongly championed by Deno to the point where I believe Deno just went the wrong way with it.

我明白了，您想保持客户端和服务器上编写的代码之间的兼容性。 但是Deno如此强烈地支持它，以至于我认为Deno的做法是错误的。

Node doesn't support "secure runtime" - and after much thinking, I believe there's little reason to support it, either.

Node不支持“安全运行时”-经过深思熟虑，我相信也没有理由支持它。

1. It's a known fact that you should not run untrusted code/executables on your systems. That is the whole point of always opting in for libraries like express for Node, instead of a shady npm module saying it works 100x faster than express. The trust comes from community usage.
   众所周知，您不应在系统上运行不受信任的代码/可执行文件。 这就是始终选择像Express for Node这样的库的全部要点，而不是一个阴暗的npm模块说它的工作速度比express快100倍。 信任来自社区使用。
2. I don't know any programming language that supports such sandboxing at its core. While it may be fancy, it just seems like something which should be done by a container environment, like Docker. I would trust a good setup Docker configuration running untrusted Node code all day above running untrusted Node code in a sandboxed Deno environment. Why? Because Docker is a billion-dollar company built around only that one single purpose - sandboxing.
   我不知道任何支持这种沙箱的编程语言。 尽管这可能不错，但似乎应该由诸如Docker之类的容器环境来完成。 我会相信一个良好的设置Docker配置，要比在沙盒化的Deno环境中运行不受信任的节点代码整天运行不受信任的节点代码。 为什么？ 因为Docker是一家市值十亿美元的公司，仅围绕一个单一目的(沙箱)建立。
3. Sandboxing is hard - I'm no cybersecurity guru, but the more features something has, the bigger the attack surface area. Deno promises a secure runtime environment, and I would not say in any way that it could be compromised right away. But I'm merely stating a fact here - Security is hard to implement right. Deno is taking a massive responsibility here. The biggest corporates in the world run their whitehat programs and flush out hundreds of millions of dollars every year to independent individuals and security firms. Where does Deno stand in terms of its truly secure environment? Time will tell.
   沙盒很难-我不是网络安全专家，但是某些功能越多，攻击面就越大。 Deno承诺提供一个安全的运行时环境，我不会以任何方式说它可能会立即受到损害。 但是我只是在这里说明一个事实-安全很难实现。 迪诺在这里承担着巨大的责任。 世界上最大的企业运行其白帽计划，每年向独立的个人和安全公司注资数亿美元。 就真正安全的环境而言，Deno站在哪里？ 时间会证明一切。

So, what can Node learn from Deno about this? I would say not a lot. Node *might* want to bring some secure environment flags from their competitors, but I just don't see a point. If you randomly run arbitrary code on your systems, you might as well clone a C/C++ repo and run a make command over it and get your whole system compromised.

那么，Node可以从Deno那里学到什么呢？ 我会说很多。 节点*可能*希望从竞争对手那里获得一些安全的环境标志，但是我只是一点都没有。 如果您在系统上随机运行任意代码，则最好克隆C / C ++存储库并在其上运行make命令，从而使整个系统受到损害。

As far as I know, you cannot "sandbox" filesystem or network access on such low-level languages like C/C++ – it's just not efficient.

据我所知，您不能在像C / C ++这样的低级语言上“沙盒”文件系统或网络访问–效率不高。

Note: Recently I discovered that you can pretty much do everything with Deno with the --allow-run flag enabled. This video dives in details:

注意：最近我发现启用--allow-run标志的--allow-run几乎可以完成所有操作。 该视频详细介绍了以下内容：

支持TypeScript (TypeScript support baked in)

Hurray for TypeScript. I'm truly happy that Deno supports it out of the box.

为TypeScript欢呼。 对于Deno开箱即用的支持，我感到非常高兴。

NOTE: Thank you @lilasquared for pointing out deno runs .js files out of the box too. Please read the further paragraphs keeping in mind we're coding in .ts files. Deno works fine with .js files too.

注意：感谢@lilasquared指出deno也可以直接运行.js文件。 请记住其他段落，请记住我们正在使用.ts文件进行编码。 Deno也可以与.js文件配合使用。

But let's roll back a little. Do you know why JavaScript (and Node) has a trillion developers across the globe? Because the entry barrier is almost nil. JavaScript is flexible and forgives a lot of mistakes - while bringing in some of the weirdest behavior you'd expect from a deterministic computer.

但是，让我们回退一点。 您知道为什么JavaScript(和Node)在全球拥有数万亿开发人员吗？ 因为进入壁垒几乎为零。 JavaScript是灵活的，可以避免很多错误-同时带来了确定性计算机可能带来的一些最奇怪的行为。

This is super bad for production-level applications where you want no funky stuff going around. And for learners, it's forgiving - which might frustrate you with nasty bugs sometimes. But also lets people to get away with their mistakes initially. It allows them to "move fast and break things", if I can quote.

对于生产级应用程序来说，这是非常糟糕的，在生产级应用程序中，您不需要时髦的东西。 对于学习者来说，这是宽容的-有时可能会让您感到讨厌的bug。 而且还可以使人们最初摆脱错误。 如果我可以引用的话，它可以使他们“快速行动并打破事情”。

With beginners, I fear that if they opt-in for Deno (which mandates the use of TypeScript), we'll be seeing a lot of code like this because they don't understand TypeScript yet and just want to run JavaScript on the server:

对于初学者，我担心如果他们选择使用Deno(强制使用TypeScript)，我们会看到很多这样的代码，因为他们还不了解TypeScript，只想在服务器上运行JavaScript。 ：

const httpResponse: any = await getAPIResponse({ myParams })
// ...
const someOtherVariable = something() as any
// ...
any, any, any

TypeScript is a superset of JavaScript. You can write bad TypeScript code too – just using it doesn't make your JavaScript bulletproof.

TypeScript是JavaScript的超集。 您也可以编写错误的TypeScript代码-仅使用它并不能使您JavaScript防弹。

It's all fun and good until you realize you can write Node code in TypeScript. I'm certain that every major company using Node in production is writing Node in TypeScript - zero exceptions. JavaScript just isn't scalable at a point when you're dealing with multiple files, multiple dependencies, and a plethora of code.

直到您意识到可以在TypeScript中编写Node代码之前，这一切都很好玩。 我确信每个在生产中使用Node的大型公司都在用TypeScript编写Node-零例外。 当您处理多个文件，多个依赖关系和大量代码时，JavaScript只是无法扩展。

TypeScript is a revolutionary toolkit in the JavaScript ecosystem and allows the use of the best of both worlds - static and dynamic language.

TypeScript是JavaScript生态系统中的革命性工具包，它允许同时使用静态和动态语言。

To this end, Deno argues that TypeScript support should be built-in. I would ask why? Sure, you might need babel and webpack to do the job, but isn't that the whole point of having toolkits around? Don't we want to enhance the DX?

为此，Deno认为应该内置TypeScript支持。 我想问为什么？ 当然，您可能需要babel和webpack来完成这项工作，但这不是拥有工具箱的全部意义吗？ 我们不是要增强DX吗？

JavaScript is going to remain JavaScript, and if Deno were to run TypeScript (or a language like a TypeScript) directly, I would have had no problem. But it isn't running TypeScript either, it converts your TypeScript code to JavaScript and then runs it.

JavaScript将保留为JavaScript，如果Deno直接运行TypeScript(或类似TypeScript的语言)，那我将没有问题。 但是它也没有运行TypeScript，它将TypeScript代码转换为JavaScript，然后运行它。

For this point, it seems like Deno is a monolithic version of Node that bundles a test toolkit, a code formatter, and TypeScript, all at once. I can't speak for all developers but I would like the core of my programming language to be lean and add other utilities if and when I want.

在这一点上，Deno似乎是Node的整体版本，它一次捆绑了一个测试工具包，一个代码格式化程序和TypeScript。 我不能代表所有开发人员，但我希望编程语言的核心是精简的，并在需要时添加其他实用程序。

Why would I need a built-in tool for code formatting when prettier exists and has the sole purpose of code formatting? Why solve things which are not broken?

为什么在更漂亮且仅具有代码格式化目的的情况下，为什么需要内置工具来进行代码格式化？ 为什么要解决没有坏的事情？

While it is true that monolithic architecture provides a lot of tooling at the same place, it is also true that it is bulky, and a lean core is much easier to maintain and scale.

虽然单片架构确实在同一位置提供了很多工具，但它确实很庞大，而且精益核心更易于维护和扩展。

一直承诺 (Promises all the way down)

This point from the Deno 1.0 release didn't really make much sense to me as a distinction. I have all the respect for the creators of Node and Deno. But Node has something which Deno doesn't - experience and backing from a huge variety of developers across the world.

作为区别，Deno 1.0版本中的这一点对我而言并没有多大意义。 我非常尊重Node和Deno的创建者。 但是Node拥有Deno所没有的东西-经验丰富并且得到了世界各地众多开发人员的支持。

Node is contributed to by almost 3000 people and is the pioneer in asynchronous I/O handling. Sure, Deno is built on Rust and exposes a similar promise-like abstraction. But Node has got C++, and 3000 developers, and 10 years of work + experiment results.

Node由近3000人贡献力量，并且是异步I / O处理的先驱。 当然，Deno建立在Rust之上，并公开了类似诺言的抽象。 但是Node有C ++，3000名开发人员以及10年的工作和实验结果。

Node's asynchronous model is not broken, promises and event listener models are not broken, so I'm unsure how Deno can fix what's not broken.

Node的异步模型没有损坏，promise和事件侦听器模型也没有损坏，因此我不确定Deno如何解决未损坏的问题。

哈斯塔斯塔维斯塔 (hasta la vista, npm)

Huge thing. Deno doesn't support NPM. As much as Ryan, the creator or Node and Deno promotes "Go" language in this point, I'd like to mention a few package managers:

大事 Deno不支持NPM。 关于这一点，Ryan或Node and Deno的创建者都在推广“ Go”语言，我想提及一些软件包管理器：

1. npm for JS (obviously)
   JS的npm(显然)
2. apt-get
   合适的
3. composer (PHP)
   作曲家(PHP)
4. brew (macOS)
   酿造(macOS)
5. cargo (Rust! - The language in which Deno is coded in)
   货物(Rust！-Deno的编码语言)

I just believe it's a wrong move to not use a package manager. They do a lot of things - versioning, running scripts, managing dependency updates, etc. Why Deno won't use npm? I don't know. But here's what I can think about:

我只是认为不使用包管理器是错误的举动。 他们做很多事情-版本控制，运行脚本，管理依赖项更新等。为什么Deno不使用npm？ 我不知道。 但是，我可以考虑一下：

1. Firstly, because they're JavaScript - and Deno needs TypeScript. CORRECTION: Deno can work with .js files as well.

   首先，因为它们是JavaScript，并且Deno需要TypeScript。 更正： Deno 也可以使用.js文件。

2. Next, a lot of these npm modules would require filesystem/networking/other permissions - which Deno restricts by default. So you need to mess around with some new "permissions" field in package.json. Oops, Deno doesn't work with npm, hence no package.json, let's see how it handles the module system then.
   接下来，许多这些npm模块将需要文件系统/网络/其他权限-Deno默认限制。 因此，您需要弄乱package.json中的一些新“ permissions”字段。 糟糕，Deno无法与npm配合使用，因此也没有package.json，让我们看看它如何处理模块系统。
3. NPM modules are bloated and there are a lot of them, but at the same time, that's the powerhouse of the Node ecosystem. Want a package to extract tar files into a stream? You got it (tar-stream). Want a data validation package? You got it (joi). Want to work with JWT? You got it (jsonwebtoken). I wonder how long it will take for developers to port their packages to a Deno-compatible system?
   NPM模块are肿，并且有很多，但同时，这也是Node生态系统的强大力量。 是否需要一个软件包将tar文件提取到流中？ 你明白了(焦油流)。 需要数据验证包吗？ 你懂了(joi)。 是否想与JWT合作？ 知道了(jsonwebtoken)。 我想知道开发人员将其软件包移植到兼容Deno的系统需要多长时间？

Deno has a different approach to module systems altogether. If, in any case, it tries to "patch-in" existing NPM modules somehow, I do not see the point in using Deno apart from just hacking around a TS + Node project inside a Docker container anyway.

Deno完全对模块系统采用了不同的方法。 无论如何，如果无论如何，它试图以某种方式“修补”现有的NPM模块，那么除了在Docker容器内破解TS + Node项目外，我看不出使用Deno的意义。

According to what I've learned about Deno so far, here's how it looks:

根据到目前为止我对Deno的了解，它的外观如下：

Deno = (mostly) [TypeScript + Node + Correctly configured docker container + single executable binaries + - NPM] Deno =(主要是)[TypeScript +节点+正确配置的docker容器+单个可执行二进制文件+ <这里和那里的一些小工具>-NPM]

Alright! Let's cool down things a little and let me conclude this article.

好的！ 让我们稍微冷却一下，让我结束本文。

结论 (Conclusion)

I'm as excited about Deno as everyone else. But when there's a complete rewrite to the JavaScript runtime, I'm expecting big changes.

我和其他所有人一样对Deno感到兴奋。 但是，当完全重写JavaScript运行时时，我期望会有很大的变化。

Deno includes a bunch of nice features like automatic TypeScript documentation, which I didn't mention because this post aims to show the other side of the coin. You'll find the advantages of Deno in almost every other article, but I believe this is something that needed to be said.

Deno包括许多不错的功能，例如自动TypeScript文档，我没有提到，因为这篇文章旨在展示硬币的另一面。 在几乎所有其他文章中，您都会发现Deno的优势，但是我认为这是需要说的。

To be honest, Deno seems like a big undertaking for a small benefit with a huge debt of transferring existing npm modules and codebases. Do you agree or disagree with me? I would like to know your opinions. Tweet/follow me: @mehulmpt and on Instagram too!

坦白地说，Deno似乎是一项大事，却为小利益带来了巨大的负担，那就是转移现有的npm模块和代码库。 你同意还是不同意我？ 我想知道你的意见。 鸣叫/关注我： @mehulmpt以及Instagram ！

Peace!

和平！

翻译自: https://www.freecodecamp.org/news/why-deno-is-a-wrong-step-in-the-future/

node deno