Deno会在短时间内取代Node吗？

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。

原文出处：https://blog.bitsrc.io/what-is-deno-and-will-it-replace-nodejs-a13aa1734a74

 

Deno是什么？

Deno v1.0.0已于5月13日正式发布。

其开发者为Ryan Dahl，他的上一个项目是Node，相信咱们大部分人都了解。

做为Node之父，Ryan Dahl认为Node自从他把项目移交出去后，Node的走向愈来愈背离了他的初衷，而且存在着不少没法解决的问题，因此他决心从新开发一个新的项目去解决这些问题，这个项目就名为Deno。目标则是Destroy-node。

那么，这样是否是就意味着Deno即将替代Node，成为Node的下一代产品？咱们应不该该从如今就开始放弃Node开始使用Deno呢？ 让咱们一块儿看看。

起源

在2018年，Ryan在柏林进行了一次演讲，这是他第二次关于JS的公开演讲，第一次再2009，那次是宣布Node项目的诞生。

在此次演讲中，除了主要介绍他认为Node.js的几大问题和不可避免的许多Bug外，在演讲快结束时，他揭开了当时仍是个小项目名为Deno的面纱，由于和node命名有着千丝万缕的联系，那时你们认为这个项目就是Node.js v2，它将会解决和完善ry提到那些问题。

两年后的5月13日， Deno 1.0终于正式发布了，它是一个全新的服务端JavaScript运行时，使用Rust而不是C++开发，因为Rust原生支持WebAssembly，因此它也能直接运行WebAssembly。基于Tokio平台(它提供了全部JavaScript所需的异步操做)，内置V8和tsc引擎，可直接解释JavaScript和TypeScript。

安全集成

默认状况下，Node.js给你的访问权限比较高，这意味着你拥有读写文件系统、对外发出请求、访问环境变量等行为。虽然做为开发人员，拥有这种级别的访问权限对开发过程很是好，但若是你在开发过程当中有一点疏漏，未来对你的应用也会产生安全风险。

而在Deno这，默认状况下脚本不具备读写权限，必须显式经过命令行参数来启用或禁用对不一样安全功能的访问。所以，若是须要脚本可以访问/etc文件夹，能够经过下面命令行执行：

deno --allow-read = / etc myscript.ts

 

这就相似于其余平台处理安全性的方式。若是你是Android用户，那么确定有不少应用程序要求你容许它们访问你手机内的不一样资源，例如联系人、电话、文件夹等，一样的概念也能够在这里应用。经过将这些标志用做执行脚本的命令行的一部分，你能够提供代码所需的权限。

更完整的标准库

自从Node的第一个版本发布以来，JavaScript已经改进了它的标准库，但与其余语言相比，它仍有至关长的路要走。Deno也试图改进这一点，它声称拥有一个很是完整的标准库，容许开发人员使用官方工具执行基本任务，而只须要对复杂任务使用外部库(ala NPM)。

本质上，Deno开箱即用工具为终端文本添加颜色，处理外部数据结构(如Binary、CSV、YAML和其余)，生成UUID，甚至编写WebSocket。还可使用其余更基本的模块，例如文件系统访问、日期助手函数、http相关函数等等。

集成TypeScript

若是你对TypeScript很是熟悉，那么使用Deno将会更加容易上手，由于它原生能够直接运行TS。

另外，Deno不须要任何外部工具去支持多语言，它内部会根据文件后缀自动判断其使用的语言解释引擎。

虽然默认状况下Deno会处理不少事情，但您可使用本身的tsconfig.json文件覆盖配置：

deno run -c tsconfig.json [your-script.ts]

默认配置使用的是严格模式，所以若是发现任何不合格的代码都会当即获得提示。

放弃NPM和node_modules

Deno决定彻底放弃NPM和node_modules， 由于npm逻辑愈来愈复杂，node.js对外部模块几乎没有任何安全验证措施，另外node_modules也愈来愈臃肿且难以管理。

 

那么，Deno是如何处理依赖关系呢？它是经过url加载全部模块的：

import * as log from "https://deno.land/std/log/mod.ts";

因此，Deno再也不须要拥有一个集中的存储库，以前的package.json也再也不须要了，如今经过在名为deps.ts的文件中包含了模块列表及其各自的URL，简化了依赖管理。但版本管理控制怎么办呢？做者已经想到了，可在URL上指定包的版本，deps.ts的文件示意：

export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";

因为这个文件的存在，在内部运行时，依赖项将被从新导出，这就能让应用程序的不一样模块都引用相同的源。

若是您想更新任何模块的版本，能够经过修改deps.ts中URL的版本信息。另外，虽然没有了node_modeules目录，但依赖项仍然会下载并隐藏在你的硬盘中，供你离线使用，如经过须要从新下载，只需在命令中添加—reload命令便可。

 

还有什么？

Deno还包括其余特性，好比自动测试器、调试器、文件监视器等开箱即用的工具。但其中一些只是语言提供的API，您须要编写本身的工具才能使用它们。

以Deno.watchFS向您提供的文件监视器API为例，若是你正在寻找相似于nodemon的解决方案，那么你能够本身构建它。下面是一个解决相似问题的23行脚本：

 

最后，它会在短时间内取代Node.js吗？

虽然Deno的不少想法和理念很是好，也确实解决了不少问题。但做为一个从Node发布之初就开始用的团队，我认为PHP、Python甚至Ruby(更不用说Java或.NET)都不能与在后端拥有JavaScript和异步I/O模型相提并论。这些年来，Node(和JavaScript)不断发展，以知足业界的需求。

在我看来，虽然Deno是以Destroy-node为己任而开发的，但就目前来说，Deno取代Node仍不可能，Node的占有率过高了，生态也足够完善，基本属于想要什么功能都能在社区中找到，因此基本无需担忧。而Deno还在孵化初期，企业很难去放弃已经成熟的技术转而投入更大的精力使用它。但它将来的前景仍是使人期待的， 也许在愈来愈多的行业头部企业分享过它们的使用经验后，Deno的存在也会愈来愈为人所知。