Node Bug 太多惨遭创始人抛弃，前端开发要变天？

点选下方“CSDN”，优先选择“首页社会公众号”

危急关头，第三天数送抵！

曾 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 必须提供扩展；

通过远程 URL 方式引入依赖而非通过本地模块，且在第三次运转时进行加载和缓存。只有在使用 –reload 运转，依赖才会更新。

可以通过指定非默认缓存目录来完成交付。

▌将 TypeScript 编译器内置于可执行文件当中

TS 很强大：

它终于实现了一类实用的可选类型语言。

且代码从快速构建到大型架构有良好的扩展。

Deno 将挂钩到 TS 编译器中, 以实现模块解析和构建结果的增量缓存。未修改的 TS 文件不能再再次编译。此外，普通的 JS 也可以工作（道理很简单，因为 TS 是 JS 的超集）。最后应该使用 V8 快照来实现快速启动（目前原型结构设计还没有这一功能）。

▌以最小的关联运转两个可执行文件

> ls -lh deno

deno

> ldd deno

c6797a000)

a47000)

6c5000)

3bc000)

1a6000)

c000)

c64000)

▌发挥 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

  征稿啦！

————— 推荐阅读 —————

点选图片即可阅读