共计 2168 个字符，预计需要花费 6 分钟才能阅读完成。
作者：Deno 一出世便带着光环 —— 它公布于 Node.js 创始人 Ryan Dahl 的演讲「Design Mistakes in Node（幻灯片）」，过后有些人说 Node.js 要凉了，但我不这么认为。
原生 TypeScript
其实目前咱们在引擎的「用户态」去应用 TypeScript 并没有引入任何问题，而且给用户带来了很大的灵活性。思考到 TypeScript 不可能来到 JavaScript 的生态 —— 毕竟引擎总是要反对 JavaScript 的；再加上 TypeScript 有不同的版本、不同的编译开关，在用户态应用 TypeScript 能够说是最好的计划了。TypeScirpt 迟早会成为 Deno 的历史包袱。
从性能的角度，在 TypeScript 没呈现之前，V8 曾经在 JavaScript 上进行大量 魔法优化 了，能够说 JIT 进去的代码并不比其余动态类型的语言差太多，是没法简略地通过 TypeScript 来晋升性能的。再加上后面说了引擎总还是要反对 JavaScript、TypeScript 的运行时语义仍然是 JavaScript（TypeScript 并不能保障对象的理论类型在运行时不被批改），所以引擎也不可能从对 JavaScript 的魔法优化切换到基于 TypeScript 的类型来做优化。
包管理器
我始终认为 NPM 是最好用的包管理器之一，这包含将依赖保留在我的项目目录中 —— 在调整一个我的项目的依赖时不用放心对其余我的项目产生影响；每个包都能够指定本人的依赖版本，容许多版本并存 —— 在降级一个包的依赖时不会影响到其余包，每个包都能够应用新的版本或持续应用旧的版本；NPM 负责查找和安装包，而 Node.js 则用绝对简略的协定去应用这些包，它们能够彼此独立地降级演进。
能够看到 NPM 最终极大地加重了开发者的心智累赘，只有你依照正确的形式去应用它，极少会遇到其余语言中无关依赖治理的问题。而 Deno 则反其道行之。尽管 Deno 也提供了一些相干的性能（deno cache），但你会发现 Deno 的本意依然是不心愿进行「依赖治理」。
在代码中蕴含 URL 是一个十分蹩脚的做法（Golang 也是如此），Deno 称之为去中心化，但其实它只是从新将应用包的代码与包的起源耦合在了一起（当初 Deno 提供了一个 官网的代理，但这样和 NPM 的核心仓库又有什么区别呢）。缓存机制也带来了相当大的不确定性：package-lock.json 能够保障每次装置的依赖是完全一致的，而 Deno 的 lock.json 只能查看依赖是否有变动（如果有的话就回绝运行）。这使得开发者很难管制依赖更新的机会，Deno 则倡议将依赖缓存放入 Git。
内建权限零碎
始终以来通用编程语言都未曾在语言层面引入权限管制，但的确开源社区也曾报出过屡次恶意代码的事件，但 Deno 的权限机制相当毛糙 —— 只能在过程级别进行权限管制，我能够大胆地预言，在简直所有的场景里咱们都须要 –allow-all，并不能对平安起到太多作用。
咱们须要思考 Deno 的用户到底是开发者还是使用者：对于 Deno 脚本的使用者来说关注的当然是过程级别的权限；而对于开发者我认为更关注的是第三方包的权限，权限零碎应该以包为单位（然而 Deno 里并没有包的概念了），Node 里原本也有 vm 模块能够肯定水平上实现沙盒（但的确十分难以管制）。
而且说起来咱们当初曾经有了 Docker（或者更宽泛的容器的概念）这种彻底的隔离和权限管制机制，业界对编程语言引入一套权限管制曾经没有太大的需要了。
孤立的生态
能够说 JavaScript 的生态来自于用户态类库的充沛竞争，Deno 则在 Runtime API 之外提供了 Standard Library（相似 golang.org/x）、提供了全套的开发工具链（fmt、test、doc、lint、bundle），在试图提供开箱即用的应用体验的同时，也减弱了第三方生态。
在 Node.js 和 NPM 未然成为 JavaScript 事实标准的一部分的状况下，Deno 原本能够通过兼容 Node.js 或 NPM 有一个十分好的收场。但 Deno 却抉择了和 Node.js 划清界限，而是兼容了一些浏览器环境的 API（如 prompt 或 onload）。
Deno 本人的说法是为了遵循已有的 Web 规范防止创造新货色，但实际上这些 Web 规范在设计时并未充分考虑浏览器之外的 Runtime，况且 Deno 其实也没能防止创造新货色（这些新货色被放在了 Deno 这个命名空间中）。
小结
Deno 就是这样一个有着十分显明集体偏好的 JavaScript Runtime，它试图去纠正 Node.js 的一些「设计失误」、心愿给出一种「JavaScript 最佳实际」，心愿提供高质量且开箱即用的规范库和工具链。这些偏好的抉择总会有人喜爱或不喜爱，但除此之外 Deno 切实是短少一个 killer featue（杀手级个性）让一个「感性」的 Node.js 开发者（如一个公司）切换到 Deno。
通过繁多文件发行、过程级别的权限管制使 Deno 会更适宜命令行工具的开发，但是否与曾经宽泛用于命令行工具的 Golang 竞争尚且存疑。
作为一个 Node.js 开发者，我并不感觉 Deno 能够在将来代替 Node 成为我的主力开发工具，Deno 更像是 Golang 的设计哲学对 JavaScript 的一次入侵。
原文地址：咱们并不需要 Deno
