今年五月份Deno发布了1.0版本，作为一个经常用Node来构建项目的前端，对Deno官网描述的那几点优点其实并不太关心(Deno优点)。主要还是想知道Deno的性能怎么样，用Deno能不能大幅减少前端构建项目的耗时。对网络上Deno能不能替代Node的讨论也比较感兴趣，于是便用Deno跟Node去执行一些常用的方法，比较它们的性能，研究下Deno是否可以替代Node。
Deno简介
Deno是一个JavaScript和TypeScript运行时，跟Node、Java一样可以运行在服务器上。
测试信息
Node版本v14.6.0(v8-8.4.371.19)，Deno版本1.1.0(v8-8.4.300)。
执行结果是执行了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 33.559ms-41.608ms
deno 63ms-83ms
base64(文件大小为2.6M)
console.time("Base64");
Base64.encode(data);
console.timeEnd("Base64");node 572.197ms-662.004ms
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 1.286s-1.343s
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 49.773ms-65.803ms
deno 41ms-49ms
JSON 序列化(10万个属性)
console.time("JSON");
let result = JSON.parse(JSON.stringify(dataObject));
console.timeEnd("JSON");node 345.198ms-376.225ms
deno 173ms-192ms
自定义loader(生成了大概202个文件)
webpack打包项目中loader占用的时间挺多的,而最常用的babel-loader简单说是把文件转换成AST，处理AST之后再重新返回。我们可以模拟下这个过程。
我的做法是复制acorn、estraverse和escodegen这三个文件，把这三个文件改成Deno可以引用的形式。然后自定义loader的代码处理逻辑Node跟Deno一样，都是读取目录下面的所有js文件，给所有js文件的函数名增加了一个自定义后缀，最后把重新生成的js文件输出到一个目录里。
node 2.371s-2.555s
deno 2057ms-2417ms
上面所有的测试代码都在这里，测试的结果应该会不同，但差异幅度应该是准确的。大家可以用自己的电脑跑跑看。
性能比对分析
从上面的数据我们可以看到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生态的发展情况。
转载标明出处即可。