做者：Deno 一出生便带着光环 —— 它发布于 Node.js 创始人 Ryan Dahl 的演讲「Design Mistakes in Node（幻灯片）」，当时有些人说 Node.js 要凉了，但我不这么认为。golang
原生 TypeScript编程
其实目前咱们在引擎的「用户态」去使用 TypeScript 并无引入任何问题，并且给用户带来了很大的灵活性。考虑到 TypeScript 不可能离开 JavaScript 的生态 —— 毕竟引擎老是要支持 JavaScript 的；再加上 TypeScript 有不一样的版本、不一样的编译开关，在用户态使用 TypeScript 能够说是最好的方案了。TypeScirpt 早晚会成为 Deno 的历史包袱。json
从性能的角度，在 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