Deno,它是否会完成颠覆，一统web江湖
随着Deno1.0的发布，web圈又开始火起来了。有很多人，不乏感慨，NodeJs都还没有完全整明白，现在又出来个Deno，我们先不论技术迭代更新的频率。单纯技术本身来看一下Deno相较NodeJs。
NodeJs的由来
NodeJs 是一个基于 Chrome V8 引擎的JavaScript 运行时。通俗的理解，就是它的内部集成了Chrome的V8引擎，使得javascript这门脚本语言具备了在服务器上运行的条件，所以NodeJs也被称作运行在服务器端的javascript。随着近几年来，web技术的迅猛发展，基于NodeJs的生态被快速的建立，很多大型的web应用程序也都是基于NodeJs实现的。
今天，比较火热的前端三大web框架，Vue、Angular以及React整体的体系架构，同样是依赖NodeJs完成的。NodeJs的出现，不仅快速推动了Web技术的日新月异，同时，也改变了Web工作者一度的工作模式，无论是开发效率上，还是前后端分离的开发模式上，以及应用产品的快速构建上，NodeJs都表现出了强有力的特色，这也是深受web开发者喜爱的一个原因。
NodeJs的特性
V8引擎本身是使用了最新的编译技术。这使得用Javascript这类脚本语言编写出来的代码运行速度获得了极大提升。
Node采用一系列“非阻塞”库来支持事件循环的方式。本质上就是为文件系统、数据库之类的资源提供接口。向文件系统发送一个请求时，无需等待硬盘寻址进行文件检索，当硬盘准备好的时候，非阻塞接口会pub通知Node。虽然让Javascript运行于服务器端并不是Node的独特之处，但却是其一强大功能。浏览器环境限制了我们选择任意编程语言的自由，只能运行JavaScript。任何服务器与日益复杂的浏览器客户端应用程序间共享代码的能力也只能通过Javascript来实现。虽然还存在其他一些支持Javascript在服务器端运行的平台，但发展上远没有Node迅猛，这也使得NodeJs成为事实上的平台。
nodejs作为一个新兴的后台语言，有其独特的设计特色:
单线程，通过事件轮询（event loop）来实现并行操作
Node.js可以在不新增额外线程的情况下，通过非阻塞IO对任务进行并行处理
V8虚拟机
事件驱动
支持跨平台性
Restful API
也许nodeJs的作者Ryan Dahl同javascript最初的作者Brendan Eich一样。未曾想到，他们或许不经意的一个想法与项目实践，在一经问世之后，会得到如此大的响应并迅猛发展。
Deno的出现
虽然近年来，NodeJs得到了飞速发展，然而，随着JavaScript的迭代更新发展，进而对于NodeJs本身却也衍生出一系列难以规避的问题。随着ES6 标准的发版，在其中引入大量新的语法特性。类似Promise 接口以及 ES原生模块，在NodeJs中的支持度并不理想。由于历史原因，NodeJs 必须要支持回调（callback），导致异步接口会有 Promise 和回调函数两种写法；同时，NodeJs 自己的模块规范CommonJS 与 ES 模块无法兼容，导致一直未能完全兼容 ES6新规范标准。
此外，NodeJs的模块包管理工具 npm，逻辑体系越来越庞大复杂；模块安装目录 npm_modules 依赖过重，难以管理。同时，nodejS本身也存在些安全性问题，并且其本身依赖的第三方库也很繁杂，导致在实际应用项目的开发过程中，时不时会出现库之间因为依赖问题或者版本冲突而导致程序出现异常。虽然随着npm的迭代升级，不断对其本身问题进行着迭代优化，但并没有得到彻底解决，从而在现有应用体系基于NodeJs的前提下，整个应用项目的维护与迭代升级的技术成本，相应也在不断增加，同时对相应技术框架的管理者提出了更高的要求与挑战。
从改进现有NodeJs比较重造一个新的轮子来看，或许后者相对更加容易。所以，NodeJs的作者Ryan Dahl 决定放弃 Node.js，从头写一个替代品，彻底解决NodeJs中的一些问题。
于是，Deno诞生了，Deno 是 Node.js 之父 Ryan Dahl 在 2018 年5 月发布的开源项目，与NodeJs 一样，Deno 也是一个服务器运行时，但是同时支持多种语言，可以直接运行 JavaScript、TypeScript 和 WebAssembly 程序。
它内置了 V8 引擎，用来解释 JavaScript。同时，也内置了 tsc 引擎，解释 TypeScript。它使用 Rust 语言开发，由于 Rust 原生支持 WebAssembly，所以它也能直接运行 WebAssembly。它的异步操作不使用 libuv 这个库，而是使用 Rust 语言的 Tokio库，来实现事件循环（event loop）。
Deno最初是用Go编写的，并使用协议缓冲区在特权（Go，具有系统调用访问权限）和非特权（V8）端之间进行序列化[11]但是，由于担心双重运行时间和垃圾收集压力，Go很快被Rust取代。引入Tokio代替libuv作为异步事件驱动平台和采用Flatbuffers进行更快的“零复制”序列化和反序列化，但在2019年8月，FlatBuffers最终被删除。
Deno本身也是 Rust 的一个模块。如果想在 Rust 里面使用 V8 引擎，就可以加载 Deno。它等同于 V8 的一个包装层，负责提供底层的 API，可以与 V8 引擎进行互动。
Deno在以下几个方面主要偏离Node.js
使用ES Module作为默认模块系统，而不是CommonJS。
包括用于资源获取的内置软件包管理器，因此不需要NPM。
使用具有缓存机制的快照TypeScript编译器开箱即用地支持TypeScript。
旨在与具有广泛Web API的浏览器更好地兼容。
允许控制文件系统和网络访问，以运行沙盒代码。
重新设计API以利用Promises，ES6和TypeScript功能。
最小化核心API的大小，同时提供没有外部依赖项的大型标准库。
使用消息传递通道来调用特权系统API和使用绑定。
Deno具有安全控制，默认情况下脚本不具有读写权限。如果脚本未授权，就读写文件系统或网络，会报错。只有使用必须参数，才可以打开权限。
Deno支持 Web API，与浏览器保持一致。它提供 window 这个全局对象，同时支持 fetch、webCrypto、worker 等 Web 标准，也支持 onload、onunload、addEventListener 等事件操作函数。此外，Deno 所有的异步操作，一律返回 Promise。
Deno只支持 ES 模块，跟浏览器的模块加载规则一致。没有 npm，没有 npm_modules 目录，没有require()命令（即不支持 CommonJS 模块），也不需要package.json文件。
所有模块通过 URL 加载，因此，Deno 不需要一个中心化的模块储存系统，可以从任何地方加载模块，Deno采用的是离线加载模块的方式。
Deno内置了开发者需要的各种功能，不再需要外部工具。打包、格式清理、测试、安装、文档生成、linting、脚本编译成可执行文件等，都有专门命令。
未来的Deno
Deno最终是否会取代NodeJs，业界有着不一样的看法，就技术本身而言，Deno的出现确实很好的解决了NodeJs本身的一些局限性问题。然而，就当下而言，NodeJs本身的生态已经成熟，并且与日俱增的在壮大，NodeJS社群亦在不断的就其本身问题进行着迭代优化。Deno从项目真正落地到产品应用，还有一定的路程要前行。也许它最终没有做到真正完全取代NodeJs，一统web江湖，但相信基于Deno也依然会建立起其自身的生态圈，同样也会衍生出更多推动技术革新的项目，应用于未来的web产品。相信，好的技术从不缺乏拓展者与创新者。
Deno未来会有怎样的夺目发展与应用，小屋与大家共同期待......
