风风火火吹了很久要替代nodejs的Deno终于引来了正式1.0发布。今天就来体验一下Deno究竟会给开发带来怎么不一样的体验。
依赖管理
Deno摈弃了大家惯用的npm，想必用过npm的同学都能体验到npm项目对于node_module的管理是让开发者十分头痛的。杂乱无章的排序分布和包裹诺大如天书般的package.json。我们看Deno是如何管理依赖的。
import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts"Deno则是通过URL的方式来引入依赖，初次调用会将依赖缓存到本地。这种引入依赖的方式不一必然引起一番腥风血雨的讨论。人们渴望新的管理依赖的方式，而对于这种URL管理依赖的方式利弊十分明显。Deno处理依赖有点像处理CDN上的静态，这是一大优点。缺点是这种去中心化的依赖管理当项目复杂起来管理困难，而且通过网络下载依赖到本地缓存，其实就是一个看不见的node_modules，开发者调试依赖起来将变得十分困难。而且服务还会存在宕机的情况。
URL管理依赖看似弊大于利，但本人挺喜欢这种处理方式的。可能是被NPM折磨的太久导致吧。
安全性
敲过几轮demo代码后，明显感觉到Deno对安全性有着很高的执着。
例如简单的一个TCP服务，要运行起来需要添加 --allow-net命令
deno run --allow-net helloworld.ts还有诸如--allow-write、--allow-read等安全性授权运行命令。这种缜密的安全性是值得赞扬的。但实际部署起来会不会麻烦死。。。 不同情况都要准备独立的一个脚本跑部署，系统复杂点是不是要吐了。。
独立执行文件
Deno只分发一个独立的执行文件。通过deno bundle [URL]打包成一个独立的可执行文件。而且远程脚本文件可以通过URL执行。这个特性还是很有用的。多机部署、私有化部署等些情况下该特性能发挥大作用。
Deno 提供 deno install 来安装和分发可执行代码。 deno install [OPTIONS...] [URL] [SCRIPT_ARGS...] 将把位于 URL 的脚本安装到名称 EXE_NAME 下。Deno的部署的确是挺方便的。
内置丰富的标准模块
开箱即用的TS环境（爽）。支持webassembly，能够运行wasm二进制文件（骚）。支持web标准API。这里可以看下Deno内置的window模块：
window.onload = (e: Event): void => {
console.log(123123)
}
window.onunload = (e: Event): void => {
console.log(456456)
}
console.log(window)
// --- output:
{ console, Deno, queueMicrotask, atob, btoa, clearInterval, clearTimeout, fetch, setInterval, setTimeout, performance, addEventListener, dispatchEvent, removeEventListener, window, crypto, onload, onunload, location }
123123
456456
内置的window模块的API大致上与浏览器上的window对象一致，同时Deno支持webworker多线程操作。真的对前端同学太友好啦～
内置测试模块
benchmark再见? 待探索
整体感觉
接触了Deno后，明显能感觉到Deno的野心，不止是要取代node的野心，Deno更是想要在后端的世界分一杯大羹。但一种语言如何发展并不是看他的野心和性能，而是看他的生态。目前Deno还十分年轻，生态圈十分贫瘠。无论是轮子还是周边的工具都有待开发。小众的语言比较难吸引人才投入精力进来建设，再加上如今node的生态如此繁荣，Deno的发展面临着较大的压力。个人感觉，Deno在未来大前端潮流上，不做兼容node生态的话是难以跟上队伍的。只有迎合了node的生态再加上自己的优良属性，同时降低学习成本。我感觉这才是Deno应该有的前进姿态。
虽然对Deno还是持着观望态度，但还是对Deno有着较大兴趣。也愿意为之生态做一些基层建设。刚好也有借口来磨练下ts啦～。
