往年五月份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年吧= =)。

总结

  1. 思考重构老本跟生态强度，Deno的性能如果没有比Node高出很多是难以代替Node的。
  2. Deno应该也能抓住一部分用户，对Deno长处感兴趣的敌人也有不少，而且Deno的学习老本还是绝对比拟低的(用过Node的话)。
  3. 因为Deno目前的生态还不成熟，零碎办法跟第三方库都还比拟少，所以当初不倡议企业公司在生产环境应用Deno。什么时候能用还是要看Deno生态的倒退状况。

转载表明出处即可。