共计 2653 个字符，预计需要花费 7 分钟才能阅读完成。
往年五月份 Deno 公布了 1.0 版本，作为一个常常用 Node 来构建我的项目的前端，对 Deno 官网形容的那几点长处其实并不太关怀 (Deno 长处)。次要还是想晓得 Deno 的性能怎么样，用 Deno 能不能大幅缩小前端构建我的项目的耗时。对网络上 Deno 能不能代替 Node 的探讨也比拟感兴趣，于是便用 Deno 跟 Node 去执行一些罕用的办法，比拟它们的性能，钻研下 Deno 是否能够代替 Node。
Deno 简介
Deno 是一个 JavaScript 和 TypeScript 运行时，跟 Node、Java 一样能够运行在服务器上。
测试信息
Node 版本 v12.18.0，Deno 版本 1.1.0。
执行后果是执行了 5 次雷同办法取的范畴。
第三方库用了 spark-md5、js-base64、acorn、estraverse 和 escodegen。
用 sort 排序数组 (数组长度为 20 万)
console.time("sort-array");
dataArray.sort((a, b) => {return a - b;});
console.timeEnd("sort-array");node：84.645ms-103.086ms
deno：134ms-140ms
md5(文件大小为 2.6M)
console.time("md5");
spark.append(data);
console.log(`md5: ${spark.end()}`);
console.timeEnd("md5");node 46.930ms-71.454ms
deno 63ms-83ms
base64(文件大小为 2.6M)
console.time("Base64");
Base64.encode(data);
console.timeEnd("Base64");node 557.819ms-688.570ms
deno 1216ms-1269ms
斐波那契数列 (n=40)
function fib(n) {if (n === 0) {return 0;} else if (n === 1) {return 1;} else {return fib(n - 1) + fib(n - 2);
}
}
console.time("fib");
fib(40);
console.timeEnd("fib");node 1301.254ms-1387.108ms
deno 1447ms-1616ms
for in 遍历对象 (10 万个属性)
console.time("for in");
for (let k in dataObject) {total += dataObject[k].list[0].n;
}
console.timeEnd("for in");node 39.923ms-56.622ms
deno 41ms-49ms
JSON 序列化 (10 万个属性)
console.time("JSON");
let result = JSON.parse(JSON.stringify(dataObject));
console.timeEnd("JSON");node 203.916ms-222.938ms
deno 173ms-192ms
自定义 loader(生成了大略 1500 个文件)
webpack 打包我的项目中 loader 占用的工夫挺多的, 而最罕用的 babel-loader 简略说是把文件转换成 AST，解决 AST 之后再从新返回。咱们能够模仿下这个过程。
我的做法是复制 acorn、estraverse 和 escodegen 这三个文件，把这三个文件改成 Deno 能够援用的模式。而后自定义 loader 的代码解决逻辑 Node 跟 Deno 一样，都是读取目录上面的所有 js 文件，给所有 js 文件的函数名减少了一个自定义后缀，最初把从新生成的 js 文件输入到一个目录里。
node 11049.085ms-12186.229ms
deno 8961ms-12542ms
下面所有的测试代码都在这里，测试的后果应该会不同，但差别幅度应该是精确的。大家能够用本人的电脑跑跑看。
性能比对剖析
从下面的数据咱们能够看到 Node 在数组排序、对象遍历、函数递归调用、md5 计算、base64 编码的测试体现会好一点，而在 JSON 序列化、自定义 loader 的测试中 Deno 要体现更好。
用 webpack 打包的话，自定义 loader 的测试比重应该是比其余项高的，所以 Deno 如果用来打包我的项目应该还是有肯定晋升的，从数据上看最高能晋升 20% 左右。当然，这个论断并不精确，理论开发中 webpack 的解决还是比较复杂的，真正精确的比照还是要用 Deno 实现一个 webpack。但就算是按 20% 的晋升来说，也是太少了，不足以让人放弃 webpack 的生态。比如说 Rollup 跟 Parcel 都已经宣传打包效率比 webpack 高很多，但他们当初都无奈撼动 webpack 在构建工具中的首领位置。
所以说先发劣势还是很重要的，当初 Node 的服务端框架有 Express、构建工具有 webpack、桌面端利用有 electron，这些都是比拟成熟的利用。Deno 的实现如果没有高性能的劣势还是很难去代替 Node 的。而且从 Deno 官网文档看到的是想代替 Python 的局部场景，而不是 Node。详见这里。(谁叫 Python 那么慢呢 ^ ^)
Deno 应用体验
首先 Deno 能间接执行 typescript 文件，不须要先用 tsc 进行编译。函数默认返回 promise，能够间接应用 await。反对 import() 跟 web worker，应用体验跟在浏览端还是有点像的，容易上手。
总得来说应用体验还是挺好的，比起 Node 的话就是省去了构建的功夫。
但 Deno 目前并不成熟，一些 API 还不稳固，提供的 API 也太少了，一些 Node 上提供的便捷办法只能本人从新实现。而且还有局部还实现不了，比方 os 模块的一些办法 (这个 issue 列出了一些不反对的办法)。第三方模块也还比拟少，目前只有 786 个。具体能够查看这里。
所以说尽管 Deno 公布了 1.0 版本，然而间隔生产应用还是要再等一段时间的 (不确定具体工夫，感觉要等个 3、5 年吧 = =)。
总结
- 思考重构老本跟生态强度，Deno 的性能如果没有比 Node 高出很多是难以代替 Node 的。
- Deno 应该也能抓住一部分用户，对 Deno 长处感兴趣的敌人也有不少，而且 Deno 的学习老本还是绝对比拟低的 (用过 Node 的话)。
- 因为 Deno 目前的生态还不成熟，零碎办法跟第三方库都还比拟少，所以当初不倡议企业公司在生产环境应用 Deno。什么时候能用还是要看 Deno 生态的倒退状况。
转载表明出处即可。
