Deno的性能对比开始，Deno在今年5月发布了1.0版本。作为一个经常使用Node搭建项目的前端，对于Deno官网描述的优势（Denoadvantages）我并不是很在意。主要想知道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)=>{returna-b;});console.timeEnd("sort-array");node:84.645ms-103.086msdeno:134ms-140msmd5(filesizeis2.6M)console.time("md5");spark.append(data);console.log(`md5:${spark.end()}`);console.timeEnd("md5");node33.559ms-41.608msdeno63ms-83msbase64(文件大小为2.6M)console.time("Base64");Base64.encode（数据）；console.timeEnd（“Base64”）；节点572.197ms-662.004msdeno1216ms-1269ms斐波那契数列（n=40）函数fib（n）{如果（n===0）{返回0；}elseif(n===1){返回1;}else{返回fib(n-1)+fib(n-2);}}console.time("fib");fib(40);console.timeEnd("fib");node1.286s-1.343sdeno1447ms-1616msforintraverseobjects(100,000attributes)console.time("forin");for(letkindataObject){total+=dataObject[k].list[0].n;}console.timeEnd("forin");node49.773ms-65.803msdeno41ms-49msJSON序列化（100,000个属性）console.time("JSON");letresult=JSON.parse(JSON.stringify(dataObject));console.timeEnd("JSON");节点345.198ms-376.225msdeno173ms-192ms自定义loader（生成约202个文件）loader在webpack打包项目中占用了大量时间，最常用的babel-loader只是简单的将文件转成AST，然后对AST进行处理再回来我们可以模拟这个过程。我的做法是复制acorn、estraverse和escodegen这三个文件，将这三个文件改成Deno可以引用的形式。那么自定义加载器的代码处理逻辑就和Deno一样了。Node读取该目录下的所有js文件，为所有js文件的函数名添加自定义后缀，最后将重新生成的js文件输出到一个目录下。.node2.371s-2.555sdeno2057ms-2417ms以上所有测试代码都在这里，测试结果应该不同，但差异范围应该是准确的。您可以使用自己的计算机运行和观看。性能对比分析从以上数据可以看出，Node在数组排序、对象遍历、函数递归调用、md5计算、base64编码测试等方面表现更好，而Deno在JSON序列化和自定义加载器测试方面表现更好。表现更好。如果使用webpack打包的话，customloader的测试比例应该会比其他项目高一些，所以如果使用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()和webworker，使用体验有点类似于浏览器，简单易用。总的来说，用户体验还是不错的。与Node相比，节省了搭建的功夫。但Deno目前还不成熟，部分API还不稳定，提供的API太少。Node上提供的一些方便的方法只能自己重新实现。而且还有一些不能实现，比如os模块的一些方法（这个issue列出了一些不支持的方法）。第三方模块还是比较少，目前只有786个，详情可以看这里。所以虽然Deno已经发布了1.0版本，但是还需要一段时间才能投入生产（具体时间不确定，感觉要等3、5年==）。综上所述，考虑到重构成本和生态实力，如果Deno的性能比Node高不了多少，Node是很难被取代的。Deno应该也能俘获一些用户，而且有很多朋友对Deno的优势感兴趣，而且Deno的学习成本比较低（如果你用过Node的话）。由于Deno目前生态还不成熟，系统方法和第三方库还比较少，不建议企业在生产环境中使用Deno。何时可用取决于Deno生态系统的发展。转载并注明出处即可。
