Node.js(https://nodejs.org/)
Node.js基于V8和libuv创建,跨平台,生态丰富,大家都很熟悉,我就少说两句。
Deno(https://deno.com/)
Deno的创建者,就是Node.js的创建者:Ryan Dahl。它之所以离开Node,创建Deno主要是因为以下几个原因:
历史包袱问题:比如:CommonJS和ES Modules
npm包管理机制与node_modules冗余依赖的问题
没有内置TypeScript支持
对C/C++以及安全层面(safety)的不满
(参见:https://www.youtube.com/watch?v=M3BM9TB-8yA&ab_channel=JSConf)
如果你是一个Node.js开发者,当你使用Deno时,你觉得比较新奇的地方可能是它的依赖管理方式:(通过URL路径引入依赖)
import * as _ from "https://a.com/b@4.17.21/c.ts";
还有安全策略:(你必须显示赋予应用权力)
deno run --allow-net --allow-read app.ts
Deno使用Rust语言开发,同样基于V8,但没有依赖libuv,而是使用 Rust 异步 I/O 库 Tokio 来处理异步操作和事件循环。这个库性能不错,最关键的是避免了对 C/C++ 编写的库(如 libuv)的依赖,降低了可能的兼容性问题和维护成本。(参见:https://github.com/denoland/deno/issues/2340)
Bun(https://bun.sh/)
Bun项目的核心目标有三个:优化 JavaScript 的运行速度,简化开发体验,大幅提高工具链性能。
从官方给出的资料看,这三个目标基本都达到了,先说性能:
无论是代码运行、模块解析,还是文件编译,Bun 的速度都比 Node.js 和 Deno 快数倍。(官方:在多数情况下,Bun 的性能比 Node.js 快 3 倍以上)以下是Bun官方给出的性能对比:
开发体验和工具链方面:开发者无需再安装 Babel、Webpack、Vite 或其他工具,Bun.js 集成了所有这些功能。
而且Bun与现有的 Node.js 项目和生态无缝兼容,开发者几乎不用担心迁移成本。
除此之外,Bun还提供了很多独特的能力,比如把一个js/ts文件打包成一个可执行程序(exe),如下所示:
bun build app.ts --compile --outfile app.exe
Bun使用使用 Zig 语言开发,没有用谷歌的V8(也没用libuv),而是用了苹果 Safari 的 JavaScriptCore(参见:https://developer.apple.com/documentation/javascriptcore)
txiki.js(https://github.com/saghul/txiki.js)
首先,这个项目是遵循WinterTC (TC55)规范开发的(https://wintercg.org/),这套规范规定了一组API,约定了实现跨服务器端JavaScript运行时的能力(参见:https://min-common-api.proposal.wintercg.org/#api-index)。
这个项目基于QuickJS(https://github.com/quickjs-ng/quickjs)创建,注意,这个QuickJS项目是真正的QuickJS项目的一个分支,我们之前介绍过这个分支(翻翻历史文章吧)。
这个项目内置了libuv,有趣的是,txiki.js的作者saghul同时也是quickjs-ng和libuv的积极维护者。
除了libuv之外,txiki.js还内置了libcurl(https://curl.se/libcurl/),txiki.js与网络有关的能力(fetch)都是libcurl提供的。
如你所见,这个库在尽可能的让运行时体积更小,更容易嵌入到其他进程中。
第一个目标确实达到了,发行包压缩后6M左右,第二个目标要开发者自己费一番功夫也能达到(这个以后有机会再介绍)。
下面是txiki.js Windows应用程序的相关文件
下面是命令行下的简单用法:
值得注意的是,txiki.js远没有Node.js/Deno/Bun成熟。要用的话,需要把自己的关键需求都验证一遍再用。