Deno发布1.0版本！JavaScript开发新里程？
作为一名JavaScript深度爱好者的我来说，一直保持着对Deno这个新生项目的持续关注。从它立项之初的Github Issues闹剧，到后来使用Rust替换Go进行重写，再到后面的一段静悄悄的沉默发展期，我一直时不时的去Deno的官网（https://deno.land）和Github项目（https://github.com/denoland）了解下它的进展状况。
对于Deno 1.0要在5月份发布正式版的事情，其实前些日子就已经知道，只是最近有点忙，没怎么放在心上。今天猛然想起，打开官网，发现它已赫然发布。真是可喜可贺!
到目前为止，Deno在Github的项目Star数量已经累积至5万多，可见它的真实关注度还是极高的，虽然在最早期闹哄哄的事件过后，它就从很多凑热闹的国内开发者眼中淡出了（至少在国内的技术圈中，比较少有开发者去讨论它），可是它并没有停滞它的开发进程，一直在持续发展演进，直到现在发布的1.0这样一个里程碑版本。
【一直以来，我都不知道Deno的这个logo图标到底是个啥。以为可能是条在下雨天钻出泥土的小蚯蚓? 亦或是一根弯曲的手指? 直到看到官网这次放出的大图，原来是条小恐龙的头啊......】
一直以来，动态语言都是以快速开发、高效生产见长的一类工具语言，而JavaScript则可以说是其中被使用的最为广泛的一种。随着ES规范的不断更新升级以及TypeScript的出现，JavaScript开发生态圈变得越来越完善和受欢迎。Node.js的成功有目共睹，它在Web前端开发工具圈、构建独立服务器端、以及其他的各种场景中混得风生水起。
但是，它也被它的生父Ryan Dahl指出了很多设计性错误，想了解详情的朋友可以看一下以下的这个视频：
但由于现在Node.js的使用者群体太大，导致这些问题难以被通过革新演进的方式来解决（意思就是：改还不如重新写一个......）。我们在实际的工作中也确实发现，使用Node.js开发和构建变得越来越重，我们不得不面对一大堆的工具（比如代码转译），以及深不见底的npm依赖等等，这些都让动态语言的轻便和使用乐趣在丧失。总之一句话，还是得重写一个！
TypeScript是一等公民
Deno的定位是为了解决不管是简单到一行代码就能搞定的小脚本，或者是非常有复杂度的业务逻辑。在代码复杂度大幅上升的时候，类型检查被证明是一个非常有用的提升代码质量的工具。在TypeScript大行其道的今天，Deno选择围绕TypeScript作为核心，应该是个大胆赌运又非常有光明前景的选择。总之在Deno中，你不需要任何额外的工具就能使用TypeScript。
Promise势如破竹
Node.js产生的年代早于Promise和async/await理念流行之前，因此，Node.js自带的核心API基本上都不是直接支持Promise或async/await的。它处理异步的方式是回调函数机制和事件机制（EventEmitter），比如在流API和网络API中随处可见的：
req.on('data', (chunk) => {
body += chunk;
});
req.on('end', () => {
const data = JSON.parse(body);
res.write(typeof data);
res.end();
});这种事件机制在处理复杂异步逻辑的时候会变得比较困难和不优雅。而使用Promise或async/await的话，则会在复杂异步处理方面会便利很多。我们知道，TypeScript对Promise和async/await的支持做的很好，而Deno底层所使用的Rust也有非常类似于Promise的Future机制，所以Deno中通过Rust实现的基础API都会很好的适配到Promise的形式。
关注首发公众号：默碟
API稳定性是头等大事
Deno提供了丰富的接口和组件，其中可用于和操作系统进行交互的接口都放在了“Deno”这个命名空间下，比如用于打开文件的Deno.open()这个接口。这些接口在开放之初都已经作了最大程度的仔细检查，保证在之后的版本升级中不会出现向后兼容性的问题。
而在全局命名空间中，一些我们在浏览器中非常熟悉的API会在此地，比如console、setTimeout()、fetch()、atob()等等，是的，Deno的目标是尽力将其API做到与浏览器API兼容。这个是非常有意思和有实际意义的。
当然，Deno还有许多面向Rust的API，那些接口还未达到1.0状态，会在后续持续迭代。
Deno是否到了可用状态？
作为一个全新开发的项目，而不是Node.js项目的分叉，Deno已经经历了2年的开发过程，并且肯定还会继续演化和成熟。那当前，我们是否可以将其用于生产了呢？答案是看情况，看具体需求......当然，我也不知道具体什么需求才算可以去用，可能只有真正的去实际尝试了，才会知道吧。
另外，Deno和那些Node.js时代产生的各种流行工具还不兼容，使得当前阶段如果我们要采用Deno来做事情的话，需要重新造很多的轮子。虽然有项目在做Deno和Node.js的兼容层，使得Deno可以使用npm下的各种包，但是这个工作还远未完成。Deno采用了一种完全不兼容的方式去更好的解决Node.js模块化系统的问题，但是也是会付出很多的代价，后续Deno团队和社区需要做很多的努力去抹平这条鸿沟。
性能是否杠杠的？
性能是我们选择一个语言或框架的重要指标之一。我们知道Node.js借助它的异步机制，在处理并发请求方面的能力是非常不错的，一度成为了各种语言和框架学习的标杆。而Deno在这方面表现如何呢?
根据官方的测试，由Deno实现的hello world级别的http服务可以达到稳定的每秒2.5w的吞吐量，并且最大延迟响应时间为1.3毫秒；而同等的Node.js服务的成绩是每秒3.5w吞吐量，最大延迟响应时间为2~300毫秒的跨度区间。可以这么说，Deno的http服务达到的是一个性能适中且稳定的状态。
官方认为每秒2.5w的吞吐量已经满足大多数的应用场景，如果不是的话，可能就不该选择JavaScript作为方案了。当然，随着Deno的继续发展，我们也完全有理由相信它在性能方面还会有提升的空间。
目前的一点小问题
由于Deno内部使用了微软的TypeScript编译器（TSC）来进行类型检查和生成JavaScript代码，相对于V8解析JavaScript的过程所花费的时间来说，TSC编译TypeScript代码的时间显得相当的长，因为TSC本身就是由TypeScript语言自己来写成的。官方想了挺多办法来提升其性能，但是收效甚微。留给他们的最好一条路就是将TSC移植到Rust上，这将可以提供数量级的性能改善，但这也是个大工程。官方说这个方案不会很快就开始实施，但一定会去实施。
就我一斤代码的观点来说，不管是基于技术方面的兴趣也好，还是对Deno的应用前景猜测也好，我一定会去好好的跟踪和研究Deno这门技术和动向的，并在可行的项目中尝试去实践它。学习的最好方式就是去亲自实践，在实践中去了解这门技术的思想，针对问题的解决方案，以及这门技术所附带的其他生态（比如Rust），这些对于我们技术人员来说，都是极其有价值的。