作者：LeanCloud王子婷Deno一出生就带着光环——发表于Node.js创始人RyanDahl的演讲“DesignMistakesinNode(slideshow)”，当时有人说Node.js是死了，但我不这么认为。NativeTypeScript事实上，我们目前在引擎的“用户态”使用TypeScript并没有引入任何问题，它给用户带来了极大的灵活性。考虑到TypeScript不可能脱离JavaScript生态——毕竟引擎一直支持JavaScript；再加上TypeScript有不同的版本和不同的编译开关，在用户模式下使用TypeScript可以说是最好的解决方案。TypeScript迟早会成为Deno的历史包袱。从性能的角度来看，在TypeScript出现之前，V8就已经对JavaScript进行了很多神奇的优化。可以说，JIT产生的代码并不比其他静态类型语言差多少，不可能简单地使用TypeScript来提高性能。.另外，前面说了，引擎还是需要支持JavaScript的，而TypeScript的运行时语义还是JavaScript（TypeScript不能保证对象的实际类型在运行时不被修改），所以引擎不可能从JavaScript的神奇优化切换到基于TypeScript的类型进行优化。包管理器我一直认为NPM是最好的包管理器之一，这包括在项目目录中保留依赖项——当您调整一个项目的依赖项时，您不必担心影响其他项目；每个包都可以指定自己的依赖版本，允许多个版本共存——升级一个包的依赖时，不会影响其他包，每个包可以使用新版本，也可以继续使用旧版本；NPM负责查找和安装包，而Node.js以相对简单的协议使用这些包，并且它们可以相互独立地升级和演进。可见，NPM终于大大减轻了开发者的精神负担。只要正确使用，很少会遇到其他语言依赖管理相关的问题。Deno恰恰相反。虽然Deno也提供了一些相关的功能（deno缓存），但是你会发现Deno的初衷仍然不是为了进行“依赖管理”。在代码中包含URL是一种非常糟糕的做法（Golang也是如此），Deno称之为去中心化，但实际上它只是将使用包的代码与包的源重新耦合（现在Deno提供了官方代理，但是这个和npm的中央仓库有什么区别）。缓存机制也带来了相当大的不确定性：package-lock.json可以保证每次安装的依赖完全一致，而Deno的lock.json只能检查依赖是否发生变化（如果有则拒绝运行）。这使得开发人员很难控制依赖项更新的时机。Deno建议将依赖项缓存放在Git中。内置权限系统通用编程语言从来没有在语言层面引入权限控制，但开源社区确实报告了很多恶意代码事件，但Deno的权限机制相当粗糙——仅在工艺水平。控制，我可以大胆预测几乎所有场景我们都需要--allow-all，而且它对安全性没有多大作用。我们需要考虑Deno的用户是开发者还是用户：对于Deno脚本的用户，当然重点在于进程级别的权限；对于开发者来说，我觉得他们更关注第三方包的权限，权限体系应该是以包为单位的（不过Deno里面没有包的概念），里面有一个vm模块一定程度上可以实现沙盒化的节点（但是确实很难控制）。而且说起来，我们现在有一套完善的隔离和权限控制机制，比如Docker（或者更广义的容器概念），业界对编程语言的一套权限控制的需求并不大。孤立的生态可以说，JavaScript的生态来自于用户态库的充分竞争。Deno提供了标准库（类似于golang.org/x）和全套开发工具链（fmt、test、doc、lint、bundle），在尝试提供开箱即用的体验的同时，它还削弱了第三方生态系统。由于Node.js和NPM已经成为JavaScript事实上标准的一部分，Deno本来可以通过与Node.js或NPM兼容来取得良好的开端。但Deno选择与Node.js划清界限，而是兼容一些浏览器环境API（比如prompt或onload）。Deno自己的说法是遵循现有的web标准，避免发明新东西，但实际上浏览器外Runtime的设计并没有充分考虑到这些web标准，Deno其实也没能避免发明新东西（这些new东西放在Deno命名空间中）。总结Deno就是这样一个个人喜好非常明确的JavaScriptRuntime。它试图纠正Node.js的一些“设计错误”，希望给出一个“JavaScript最佳实践”，希望提供高质量、开箱即用的标准库和工具链。总会有人喜欢或不喜欢这些首选的选择，但除此之外，Deno确实缺少一个杀手级功能（killerfeature）来让“理性”的Node.js开发人员（比如公司）转向Deno。通过单文件分发和进程级权限控制，Deno将更适合命令行工具的开发，但能否与已经广泛应用于命令行工具的Golang竞争值得怀疑。作为一名Node.js开发者，我不认为Deno可以取代Node成为我未来的主要开发工具。Deno更像是Golang的设计理念对JavaScript的一种入侵。原文地址：我们不需要Deno
