曾经 Node 的面世，将 JavaScript 首次带入了后端服务器端开发，不仅让诸多的前端开发者更能轻而易举地编写出高性能的 Web 服务，同时也大大地提高了服务器的安全性。而如今经过九年的发展，其创始人 Ryan Dahl 不仅"嫌弃"了存在很多槽点的 Node，还重新发布了一个新的开源项目——Deno，而这究竟是怎么一回事？Deno 会将 Node 取而代之吗？对前端开发者的影响大吗？接下来，我们将一一为大家解读其中背后的故事。
作者 | 屠敏
责编 | 唐小引
近日，在 2018 年的 JSConf 上，Node 之父 Ryan Dahl 发表了主题为《Design Mistakes in Node》的演讲，在演讲中，他为曾在 Node 设计上所犯的一些错误表示遗憾，并为此提出了一种新的原型设计思路，创建了一套立足于 V8 的安全 TypeScript 运行时项目——Deno。
Node 初始目标
对于 Node 最初创建的目标，主要是集中于编程事件驱动的 HTTP 服务器上。随着时间的推移，后来也验证了这一点对于当时服务器端 JavaScript 来说至关重要。遗憾的是，Node 后期并没有得到很好的维护，因为在 2012 年，已经在这个项目上耗费了四年时光的 Ryan Dahl 认为 Node 已经实现了他的预期目标，如：
- 支持多种协议：HTTP、SSL、......
- 可运行于 Windows（使用 lOCP：http://tinyclouds.org/iocp-links.html）、Linux（epoll）、Mac（kqueue）上。
- 具有稳定的 API。
- 通过 NPM 实现增加外部模块的生态系统。
且 Ryan Dahl 认为对于 Node 的后期也只需修复一下因不断增加的代码而出现的 Bug，于是他在 Node 如日中天时离开了 Node 团队。直至最近，他才发现曾经的自己错了，虽说当时 Node 已经为用户提供了一套友好的非阻塞框架，但是后续还是出现了很多不可回避的问题。
安全性不足
V8 本身是一个非常好的安全沙箱。如果当时能够对某些特定应用程序的维护更加上心，也许 Node 可以实现比其他任何语言更好的安全保障。譬如，用户的 linter 不应该具备完全访问计算机和网络的权限。
构建系统（GYP）
要知道构建系统是非常困难且重要的。最初 V8（借助 Chrome）开始使用 GYP，而 Node 也对接了 GYP，但是后来 Chrome 放弃了 GYP 而转向 GN，因此 Node 成为 GYP 的唯一用户。对于 GYP 的继续使用可能是 Node 核心最大的败笔。
对此，Ryan Dahl 认为自己不应该引导开发者基于 V8 引擎使用 C++ 编写，而是应该提供一个核心外部函数接口（FFI）。其实早前，就有很多人建议他转向 FFI，但当时 Ryan Dahl 并没在意，这让他现在追悔莫及。
最后， Ryan Dahl 还对 libuv 采用 autotools 表示非常不满意。
package.json
对于 NPM，虽然是 Isaac 创建了 package.json（绝大部分）。但最终是由 Ryan Dahl 通过了允许 Node 的 require（） 函数来检查 package.json 文件，将 NPM 包含在 Node 的发行版本中，使之成为现实中标准方案。然而，令人懊恼的是，这其中存在一个模块的集中（私有控制）存储库。
即 require("somemodule") 并非唯一，它在很多地方都被定义了。
此外，package.json 这一文件还衍生出“模块”作为文件目录的概念。这不是一种绝对必要的抽象机制，此前在 web 上也从未出现过。
如今的 package.json 文件中包含了各种不必要的信息。譬如许可、库、描述等等。
如果在导入时仅使用相关文件和 URL，则路径就可定义版本，也没有必要列出依赖关系。
node_modules
node_modules 极大地提高了模块解析算法复杂度。vendored-by-default 初衷是好的，但是在实践中，仅使用 $NODE_PATH 并不能实现预期的目的。它偏离了浏览器语义。
Ryan Dahl 表示这是他的错，且遗憾的是，这一问题如今也无法弥补。
require("module") 没有 ".js"扩展名
在脚本标签的 src 属性中，“.js”不容忽视，而在 require("module") 中没有明确地显示出 .js 扩展名。
index.js
因为已有 index.html 文件的存在，index.js 则会给模块加载系统带来不必要的复杂因素。且在已受 package.json 支持下，它将变得毫无意义。
Deno：一套立足于 V8 的安全 TypeScript 运行时
以上这些问题不仅成为其创始人 Ryan Dahl “嫌弃” Node 的原因，同时也为诸多开发者带来不少的麻烦。基于此，Ryan Dahl 使用 Go 语言代替 C++ 重新编写跨平台底层内核驱动，上层仍使用 V8 引擎，发布了一套安全 TypeScript 运行时项目——Deno。其主要目标如下：
安全
利用 JavaScript 是安全沙箱的这一事实：
- 默认情况下，应该在没有任何网络或文件系统写权限的情况下运行脚本；
- 用户可以选择通过标志访问：--allow-net --allow-write
- 允许用户运行不受信任的实用程序（如 linter）
不允许将任意本地函数绑定到 V8 中：
- 所有的系统调用都是通过消息传递完成的（protobuf 序列化）
- 确切地说有两个本地函数：send 和 recv
- 这既简化了设计，又使系统更易于审核。
简化模块系统
- 不再尝试与现有 Node 模块兼容；
- 导入只是相对或绝对URL；
import {test} from "https://unpkg.com/deno_testing@0.0.5/test.ts
import {log} from "./util.ts"
- import 必须提供扩展；
- 通过远程 URL 方式引入依赖而非通过本地模块，且在第一次运行时进行加载和缓存。只有在使用 --reload 运行，依赖才会更新。
- 可以通过指定非默认缓存目录来完成交付。
将 TypeScript 编译器内置于可执行文件当中
TS 很强大：
- 它终于实现了一种实用的可选类型语言。
- 且代码从快速构建到大型架构有良好的扩展。
Deno 将挂钩到 TS 编译器中, 以实现模块解析和构建结果的增量缓存。未修改的 TS 文件不能再重新编译。此外，普通的 JS 也可以工作（道理很简单，因为 TS 是 JS 的超集）。最后应该使用 V8 快照来实现快速启动（目前原型设计还没有这一功能）。
以最小的关联运行一个可执行文件
> ls -lh deno -rwxrwxr-x 1 ryan ryan 55M May 28 23:46 deno > ldd deno linux-vdso.so.1 => (0x00007ffc6797a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f104fa47000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f104f6c5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f104f3bc000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f104f1a6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f104eddc000) /lib64/ld-linux-x86-64.so.2 (0x00007f104fc64000)
发挥 2018 年的技术优势
通过使用 Parcel 将编译 Node 模块打包，引导运行。（这将大大地简化 Node 流程 ）。
良好的基础架构现在存在于本地代码中，EG 不需要再为 HTTP 担心。 已有其他机制负责实现相关功能（Node 中的情况并非如此，Web 服务器还需要 100％ 的手动滚动）。
目前 Deno 的非 JS 部分正在使用 Go 语言编写，对于替代语言：
- Rust 或许是一个不错的选择；
- 如果允许其他人以 Go 或 Rust 语言编写自己的 Deno 项目，C++ 可能会是一个不错的选择？
Deno 的发布对开发者意味着什么？
Deno 提高了安全性、简化了模块系统、面向 TypeScript，换句话说 Deno 主要是针对 Node 的痛点才出现的，那么 Deno 是否会取代以根深蒂固的 Node 呢？初学者是从 Deno 入手还是 Node?
对此，Ryan Dahl 表示，当然使用 Node，因为 Node 和 Deno 两者最大的区别是 Node 早已大行其道，而 Deno 开发仅有一个月的时间，还在初级阶段，仅是个 Demo 根本无法投入使用。因此，Deno 想要在短时间之内将 Node 取而代之也是不可能的。
- Deno：https://github.com/ry/deno
- PPT：http://tinyclouds.org/jsconf2018.pdf
