Deno 1.0正式发布!它能替代 NodeJS 吗?

作者 丨 Deno
团队译者 丨 王强
策划 丨小智

学不动了?不存在的!

动态语言都是很有用的工具。用户可以使用脚本快速简洁地将复杂的系统连接在一起并表达自己的想法,而不必顾虑诸如内存管理或系统构建之类的细节。近年来,像 Rust 和 Go 这样的编程语言让程序员能更轻松地生成复杂的原生代码;这些项目也是计算机基础架构发展历程中极为重要的里程碑。但是,我们认为开发工作中有一个可以应对多种问题领域的强大脚本环境还是非常重要的。

JavaScript 是应用最广泛的动态语言,只需一个 Web 浏览器就能在所有设备上运行。精通 JavaScript 的程序员数不胜数,并且社区已经为了优化 JS 的执行效率而投入了大量资源。在像 ECMA International 这样的标准组织推动下,JS 语言得到了精心而持续的改进。我们相信,无论是在浏览器环境中还是作为独立进程使用,JavaScript 都是动态语言工具链的首选。

我们在这一领域的早期项目 Node.js 被证明是一个非常成功的软件平台。人们发现它能很好地用于构建 Web 开发工具、构建独立的 Web 服务器以及其他许多用例。但是,Node 是在 2009 年设计的,当时的 JavaScript 与今天的语言版本有着明显的区别。出于用户需求考虑,Node 在当时必须发明许多概念,其中很多在后来都被标准组织采纳,并通过各种方式加入了 JS 语言规范。在“Node 中的设计错误”演讲中对这一话题有更具体的讨论。

https://www.youtube.com/watch?v=M3BM9TB-8yA

由于 Node 拥有大量用户,因此系统进化起来既困难又缓慢。

随着 JavaScript 语言的不断变化,以及诸如 TypeScript 之类的新增改进,Node 项目的构建可能会成为一项艰巨的工作,过程中需要管理构建系统和其他需要繁重操作的工具链,结果大大抵消了动态语言脚本的优势。此外,通过 NPM 存储库链接到外部库的机制本质上是中心化的,这不符合 Web 的发展理念。

我们认为 JavaScript 与其周围的软件基础架构已经在改进的道路上走得够远了,应该做一些简化工作了。我们想要寻求一种可用于多种任务的有趣且高效的脚本环境。

用于命令行脚本的 Web 浏览器

Deno 是一个新的运行时,用于在 Web 浏览器之外执行 JavaScript 和 TypeScript。

Deno 试图提供一个独立的工具来快速编写功能复杂的脚本。Deno 是(并将始终是)单个可执行文件。就像 Web 浏览器一样,它知道如何获取外部代码。在 Deno 中,单个文件可以定义任意复杂的行为,而无需其他任何工具。

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

上面的代码段只需一行代码就将一个完整的 HTTP 服务器模块添加为了一个依赖项。没有额外的配置文件,没有预先的安装工作,只需输入 deno run example.js 即可。

与浏览器一样,默认情况下 Deno 中的代码会在安全的沙箱中执行。未经允许,脚本无法访问硬盘驱动器、打开网络连接或进行其他任何可能引入恶意行为的操作。浏览器提供了用于访问相机和麦克风的 API,但用户必须首先授予权限才能启用它们。Deno 在终端中提供了模拟行为。除非提供 --allow-net 命令行标志,否则上述示例将失败。

Deno 是精心设计的,避免偏离标准化的浏览器 JavaScript API。当然,并不是每个浏览器 API 都与 Deno 相关,但只要有 API 和 Deno 有联系,后者都不会偏离标准。

一流的 TypeScript 支持

我们希望 Deno 适用于广泛的问题领域:从小型单行脚本到复杂的服务端业务逻辑都能适用。随着程序变得越来越复杂,具有某种形式的类型检查也成为编程语言越来越重要的特性。TypeScript 是 JavaScript 语言的扩展,允许用户选择提供类型信息。

Deno 无需其他工具即可支持 TypeScript。运行时在设计时就考虑了 TypeScript 的支持。deno types 命令为 Deno 提供的所有内容提供类型声明。Deno 的标准模块全部使用 TypeScript 编写。

Promise 的支持下放到底层

Node 是在 JavaScript 引入 Promise 或 async/await 概念之前设计的。Node 中与 promise 对应的是 EventEmitter,像套接字(socket)和 HTTP 这样的重要 API 则环绕其外。在 async/await 这样的设计优势外,EventEmitter 模式还存在一个背压问题。以 TCP 套接字为例。套接字在收到传入数据包时将发出“数据”事件。这些“数据”回调将以不受限制的方式发出,结果会让事件充斥整个进程。由于 Node 会继续接收新的数据事件,而底层 TCP 套接字没有适当的背压,于是远程发送方不知道服务器已超负荷,还会继续发送数据。为了缓解这个问题,Node 添加了 pause() 方法。这可以解决问题,但是需要额外的代码;而且由于事件泛滥问题只在进程非常繁忙时才会出现,因此许多 Node 程序都可能出现数据洪水的现象。结果是系统的尾部延迟时间变得很长。

在 Deno 中,套接字仍然是异步的,但是接收新数据需要用户显式 read()。正确构造一个接收套接字不需要额外的暂停语义。这不是只针对 TCP 套接字。系统的最低绑定层从根本上绑定了 promise——我们称这些绑定为“ops”。Deno 中的所有回调,无论形式如何,都是来自 promise 的。

Rust 有它自己的类似于 promise 的抽象,称为 Future。通过“op”抽象,Deno 让开发人员可以轻松将 Rust 的基于 future 的 API 绑定到 JavaScript promise 中。

Rust API

我们在 Deno 中提供的主要组件是 Deno 命令行界面(CLI)。CLI 现在是 1.0 版本。但是 Deno 并不是一个单体程序,而是设计为一个 Rust crate 的集合,以实现不同层次的集成。

deno_core crate 是 Deno 的核心骨架。它不依赖于 TypeScript 或 Tokio。它只是提供了我们的 Op 和 Resource 基础架构。换句话说,它提供了一种有组织地将 Rust future 绑定到 JavaScript promise 的方式。CLI 当然完全建立在 deno_core 之上。

rusty_v8 crate 为 V8 的 C++ API 提供了高质量的 Rust 绑定。该 API 试着尽可能与原始 C++ API 匹配。它是零成本绑定:Rust 中公开的对象与你在 C++ 中操作的对象完全相同。(例如,之前针对 Rust V8 绑定的尝试强制使用持久句柄。)这个 crate 提供了在 Github Actions CI 中内置的二进制文件,但它还允许用户从头开始编译 V8 并调整一众构建配置。所有 V8 源代码均在 crate 自身中分发。最后,rusty_v8 尝试成为一个安全的接口。它还不是 100%安全的,但我们正在接近这个目标。能够以安全的方式与像 V8 这样复杂的 VM 交互是非常棒的事情,并且让我们发现了 Deno 本身中存在的许多难以察觉的错误。

稳定性

我们保证在 Deno 中维持一个稳定的 API。Deno 有很多接口和组件,因此明确我们所说的“稳定”的含义是很重要的。我们开发的与操作系统交互的 JavaScript API 都可以在“Deno”命名空间(例如 Deno.open())中找到。这些 API 已经过仔细检查,我们不会对它们做出向后不兼容的更改。

尚未准备稳定下来的所有功能都隐藏在 --unstable 命令行标志后面。你可以在此处查看不稳定接口的文档:

https://doc.deno.land/https/raw.githubusercontent.com/denoland/deno/master/cli/js/lib.deno.unstable.d.ts

在后续版本中,其中一些 API 也会被稳定下来。

在全局命名空间中,你会找到其他所有对象(例如 setTimeout() 和 fetch())。我们已经尽力让这些接口与浏览器中的接口保持一致。但是如果发现意外的不兼容问题,我们将发出更正。这些接口不是我们,而是浏览器标准定义的。我们发布的所有更正均是错误修复,而不是接口更改。如果存在与浏览器标准 API 不兼容的问题,则它可以在主要版本发布之前得到更正。

Deno 也有许多 Rust API,比如说 deno_core 和 rusty_v8 crate。这些 API 都还不是 1.0 版本。我们将继续对它们进行迭代。

局限性

重要的是要了解 Deno 并不是 Node 的分支——它是一个全新的实现。Deno 的开发工作只经过了两年时间,而 Node 已经开发了超过十年。考虑到社区对 Deno 的兴趣,我们希望它会继续发展并成熟。

对于某些应用程序而言,Deno 可能是现下一种不错的选择,对于其他应用程序来说 Deno 还不够合适,具体取决于需求。我们希望透明地公开这些局限性,以帮助人们在考虑使用 Deno 时做出明智的决定。

兼容性

不幸的是,许多用户会沮丧地发现 Deno 缺乏与现有 JavaScript 工具的兼容性。Deno 与 Node(NPM)软件包总体来说是不兼容的。在deno.land/std/node/上建立了一个新的兼容性层,但它离完成还很遥远。

https://deno.land/std/node/

尽管 Deno 使用强硬的方法简化了模块系统,但毕竟 Deno 和 Node 是非常相似的系统,有着很接近的目标。随着时间的推移,我们希望 Deno 能够开箱即用地运行越来越多的 Node 程序。

HTTP 服务器性能

我们不断跟踪 Deno 的 HTTP 服务器性能。一个 hello-world 的 Deno HTTP 服务器每秒处理约 25,000 个请求,最大延迟为 1.3 毫秒。一个可比的 Node 程序每秒则处理 34,000 个请求,最大延迟介于 2 到 300 毫秒之间。

Deno 的 HTTP 服务器是在原生 TCP 套接字上面用 TypeScript 实现的。Node 的 HTTP 服务器使用 C 语言编写,并作为 JavaScript 的高级绑定公开。我们一直拒绝将原生 HTTP 服务器绑定添加到 Deno,因为我们要优化 TCP 套接字层,更一般地说是要优化 op 接口。

Deno 是一个不错的异步服务器,每秒 25k 请求足以满足大多数目的。(还不够用的话,那么 JavaScript 可能不是最佳选择。)此外,由于普遍使用 promise(如上所述),我们期望 Deno 一般来说能表现出更好的尾部延迟。综上所述,我们确信这一系统还能有更多的性能优势,并希望在将来的版本中实现这一目标。

TSC 瓶颈

在内部,Deno 使用微软的 TypeScript 编译器检查类型并生成 JavaScript。与 V8 解析 JavaScript 所花费的时间相比,它是非常缓慢的。在项目的早期,我们曾希望“V8 Snapshots”在这里能够带来明显的提升。Snapshots 肯定是有帮助的,但是它还是太慢了。我们当然认为可以在现有 TypeScript 编译器的基础上进行一些改进,但我们知道,显然我们最终需要在 Rust 中实现类型检查。这将是一项艰巨的任务,不会一蹴而就。但它可以在开发体验的关键路径上提供数量级的性能改进。TSC 必须移植到 Rust。如果你有兴趣合作解决这个问题,请与我们联系。

插件 / 扩展

我们有一个新生的插件系统,用于通过自定义操作扩展 Deno 运行时。但这个接口仍在开发中,并已标记为不稳定。因此,访问 Deno 提供的系统之外的原生系统是很困难的。

Chrome 81 正式发布 !消灭混合内容最后一步~

Chrome 81 于前天正式发布了,这个版本其实最初是计划在 3 月 17 号 发布的,但由于冠状病毒(COVID-19)爆发而导致推迟到了现在。Chrome 81 的延迟也扰乱了 Google 正常的六周发布时间表。因此 Google 此前也宣布,下一个版本将直接跳过 Chrome 82 ,直接发布 Chrome 83。 下面我就来带大家看看 Chrome 81 有哪些重要的更新。

发布于:1月以前  |  128次阅读  |  详细内容 »

当浏览器全面禁用三方 Cookie

苹果公司前不久对 Safari 浏览器进行一次重大更新,这次更新完全禁用了第三方 Cookie,这意味着,默认情况下,各大广告商或网站将无法对你的个人隐私进行追踪。而微软和 Mozilla 等也纷纷采取了措施禁用第三方 Cookie,但是由于这些浏览器市场份额较小,并没有给市场带来巨大的冲击。

发布于:1月以前  |  109次阅读  |  详细内容 »

H5 直播的疯狂点赞动画是如何实现的?

直播有一个很重要的互动:点赞。 为了烘托直播间的氛围,直播相对于普通视频或者文本内容,点赞通常有两个特殊需求: 点赞动作无限次,引导用户疯狂点赞 直播间的所有疯狂点赞,都需要在所有用户界面都动画展现出来(广播用户使用websocket消息)

发布于:1月以前  |  104次阅读  |  详细内容 »

探索 Serverless 中的前端开发模式

最近关于 Serverless 的讨论越来越多。看似与前端关系不大的 Serverless,其实早已和前端有了渊源,并且将对前端开发模式产生变革性的影响。本文主要就根据个人理解和总结,从前端开发模式的演进、基于 Serverless 的前端开发案例以及 Serverless 开发最佳实践等方面,与大家探讨 Serverless 中的前端开发模式。本人也有幸在 QCon2019 分享了这一主题。

发布于:1月以前  |  134次阅读  |  详细内容 »

前端需要了解的9种设计模式

设计模式是对软件设计开发过程中反复出现的某类问题的通用解决方案。设计模式更多的是指导思想和方法论,而不是现成的代码,当然每种设计模式都有每种语言中的具体实现方式。学习设计模式更多的是理解各种模式的内在思想和解决的问题,毕竟这是前人无数经验总结成的最佳实践,而代码实现则是对加深理解的辅助。

发布于:1月以前  |  116次阅读  |  详细内容 »

为什么你的网页需要 CSP?

内容安全策略(CSP)是一个 HTTP Header,CSP 通过告诉浏览器一系列规则,严格规定页面中哪些资源允许有哪些来源, 不在指定范围内的统统拒绝。

发布于:1月以前  |  107次阅读  |  详细内容 »

10 种跨域解决方案(附终极方案)

嗯。又来了,又说到跨域了,这是一个老生常谈的话题,以前我觉得这种基础文章没有什么好写的,会想着你去了解底层啊,不是很简单吗。但是最近在开发一个 「vscode 插件」 发现,当你刚入门一样东西的时候,你不会想这么多,因为你对他不熟悉,当你遇到不会的东西,你就是想先找到解决方案,然后通过这个解决方案再去深入理解。

发布于:1月以前  |  174次阅读  |  详细内容 »

移动 Web 最佳实践(干货长文,建议收藏)

笔者在公司用 web 技术开发移动端应用已经有一年多的时间了,开始主要以 vue 技术栈配合 native 为主,目前演进成 vue + react native 技术架构,vue 主要负责开发 OA 业务,比如报销、出差、crm 等等,react native 主要负责即时通信部分,是在 mattermost-mobile的基础上修改的(mattermost 是一个开源的即时通讯方案)。

发布于:1月以前  |  122次阅读  |  详细内容 »

不可错过的实用前端工具

给大家整理了 25 个前端相关的学习网站和一些靠谱的小工具,包括一些小游戏、教程、社区网站和博客,以及一些资源网站,希望可以帮助到大家!

发布于:1月以前  |  116次阅读  |  详细内容 »

理解 WebView

我们通常使用 Chrome, Firefox, Safari, Internet Explorer 和 Edge 等浏览器来浏览网页。你也许正在使用其中一种浏览器阅读本文!虽然浏览器对于访问互联网内容的任务来说非常流行,它们还有一些我们从未过多关注过的竞争对手。这些竞争对手以 WebView 的形式被我们所熟知。这片文章将讲解 WebView 的神秘之处以及为什么它这么棒。

发布于:1月以前  |  119次阅读  |  详细内容 »

Facebook 前端技术栈重构分享

当我们考虑如何构建一个新的网络应用—一个为现代浏览器设计的、具有用户对Facebook(我们已知的)所有期望的功能,我们现有的技术栈无法支持我们所需要的类似于桌面应用的感觉和性能。

发布于:1月以前  |  115次阅读  |  详细内容 »

最多阅读

为Electron程序添加运行时日志 1年以前  |  4928次阅读
初探 React 组件 1年以前  |  2187次阅读
wordpress标签页的制作 1年以前  |  2076次阅读
Node.js下通过配置host访问URL 1年以前  |  2024次阅读
js动态创建类和实例化 1年以前  |  2007次阅读
500行PHP代码搞定富文本安全过滤 1年以前  |  1974次阅读
22个HTML5的初级技巧 1年以前  |  1924次阅读
使用 SRI 增强 localStorage 代码安全 1年以前  |  1914次阅读
浅谈浏览器的原生拖拽事件 1年以前  |  1887次阅读
第三版主题上线 1年以前  |  1885次阅读
CSS清除浮动 1年以前  |  1877次阅读
2014年度总结 1年以前  |  1823次阅读
【译】V8 团队眼中的 ES6、ES7及未来 1年以前  |  1817次阅读
利用服务器返回header来传输数据 1年以前  |  1807次阅读
获取元素的计算的样式 1年以前  |  1801次阅读