近日，Node 之父 Ryan Dahl 发布新的开源项目 deno，从官方介绍来看，可以认为它是下一代 Node，使用 Go 语言代替 C++ 重新编写跨平台底层内核驱动，上层仍然使用 V8 引擎，最终提供一个安全的 TypeScript 运行时。 它的特性包括：
支持 TypeScript 2.8 开箱即用；
无 package.json，无 npm，不追求兼容 Node；
通过 URL 方式引入依赖而非通过本地模块，并在第一次运行的时候进行加载和缓存，并仅在代码使用–reload运行，依赖才会更新，引入方式如：
import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts" import { log } from "./util.ts" 可以控制文件系统和网络访问权限以运行沙盒代码，默认访问只读文件系统可访问，无网络权限。V8 和 Golang 之间的访问只能通过 protobuf 中定义的序列化消息完成；
发生未捕捉错误时自动终止运行；
支持 top-level 的 await；
最终创建单一可执行文件；
目标是兼容浏览器；
可以作为库引入，用于建立自己的 JavaScript runtime。
这几个特性，有好几个都是针对目前 Node 的痛点而来的，包括无 package.json、依赖的引入和更新方式，针对的就是被广泛吐槽的过大的node_modules。
同时，不追求兼容 node，可以视为 ry 想彻底抛弃 node 包袱，打造一个更好的 JS 运行时。
作者在 GitHub Issue 回复开发者的几个问题：
deno 和 Node 的区别是什么？ ry 开玩笑称，目前两者最大的区别是 Node 大行其道，而 Deno 尚未投入使用。
从更高层面上来说，Deno 尽可能简化 V8 与系统 API 的耦合，并打造更加简单、稳定的模块系统，以及一个安全的沙箱运行环境。
再者，使用 Golang 而不是 C++ 作为底层语言，这样，添加高级功能时会比在 Node 中更加容易，比如在 Go 中添加 http2.0支持，只需添加一些路由 API 和一些配置到 protobuf 中。
Deno 诞生的目的，是为了创建更简单和安全的非浏览器 runtime，它在这个时候出现，是因为现在的开发工具比 2009 年更好。
我们还可以认为 Deno 将是目前 Node 生态一些难解问题的终极答案，比如依赖管理、安全性、稳定性、横向扩展等等。
Deno 的诞生，将启发更多人投入到下一代 Node 的探索当中，这比之前 Node 的一些分叉更具备创新和革命性。
目前 Deno 正在紧张开发当中，我们也将持续关注它的进展。
Deno Github 地址： https://github.com/ry/deno
在前端之巅公众号上看到的，跟大家分享一下，欢迎大家一起讨论
创世之神果然关注率高，估计明天能攒到 5000颗星，一周内估计要突破万星，预计会是2018年最牛B 闪闪的github 项目了。 typescript 这是要起飞了吗？
同意，与其这样画蛇添足的做个V8绑定，还不如直接用go。
go本身是一个不上不下的语言，用go绑定V8那就更加匪夷所思了。
go开发效率不比Typescript差，能用go直接开发何必再包一层runtime呢？
后端开发Typescript的语言特性远不如go，JavaScript更加不如，这种绑定意义何在？
node还是老老实实的去做前端工具链，做好大前端的角色就行了，其余情况跟其他新兴的后端语言比真的没有优势。
后端根本不是语言的事，不管Javascript还是Typescript还是go，学语言的难度远比后端其他技术容易得多。
@coordcn 语言的本质是沟通，语言的形成是存在历史原因的（浏览器选择javascript 是历史的选择）， 说语言有优劣性是可以的； javascript 语言本身的有很多问题是事实， typescript 是对javascript 的改良版也必然会有不足的遗留，但已经是提供了一个更好的选项。 RY 有心想作更好的Node 改良版，个人觉得也是意义非凡的。 你不得不承认 Go 是无法替代 javascript 的 ( 你也可以说ts 也无法替代 js, 但 ts 目前存在但价值意义是无可置疑的); 而deno 能直接运行 ts 而不是编译后的js， 就这点就足够吸引人了
算了成本自然就明白了，这里不是打语言炮，go，Typescript和javascript都有各自的缺陷，从实践情况来讲，go的语言特性更适合后端，虽然协程加channel的模式还不完美，但go在开发效率，运行效率，编程模型上做了恰当的妥协，Typescript，javascript除了能够满足前端程序员无语言痛转后端，其他还能举出胜于go的地方么？我三种语言都用，我个人更加倾向于选择合适的语言在合适的领域做合适的事情，而不是为了照顾一些不愿意学习新语言的程序员，在其他语言上再套一层runtime。
除了个别牛人，全栈其实就是个伪命题，大部分所谓的全栈其实就是前端不强，后端不行，两边都是半瓶水。
下面开始计算成本
新语言学习成本，类C语言，javascript转go不会有多大不适应，如果有良好的C语言基础，基本是无痛的，语言概念，javascript也有协程概念，go语言做得更好，抽象得更彻底，go只会比javascript那种stackless伪协程更舒服。
包装成本，v8（cpp）到go，再到TS，比原生的nodejs的绕了个大圈子，nodejs又不是不能用Typescript写。
生态成本，这个项目能够复用nodejs的生态么？如果能，如何保证生态复用是安全可靠的？这需要大量的测试工作，如果不能，一个没有生态的东西怎么可能撼动生态丰富的nodejs？
后端技术栈，这部分才是后端的精华，就如后端的人会javascript，但整个前端技术栈掌握远不如前端大牛一个道理，后端的大部分学习成本不在语言上。
综上所述，这个项目就是个鸡肋，大家可以拭目以待，让时间证明一切。
@coordcn 不打语言炮( 不评论哪个语言的优劣)， 你说你三种语言都用，为何都用了呢？说明你的沟通对象里面有需要，并且适用用这个语言来沟通需求对吧（这即体现语言的本质是沟通）？ 另外比如说你和一个外国友人交流，发现只用英语无法表达了，你可能换个肢体语言来沟通，表达恰当，对方便立即明白了，这个就是语言的效用， 这里不能说肢体语言比口语好或者不好就抛弃掉谁吧？ 回到deno 的意义上，你说鸡肋不鸡肋，就看 ts 是转成js 运行就都已经满足大家的需求了，还是直接运行来的更好（毕竟只是 ts-node 这样还是不够的）。 当然还有存在的可能性就是看其他的一些特性，比如异步模型、模块、包管理还能不能更好的改进（这个目前还不得而知）。
另外 “全栈其实就是个伪命题，大部分所谓的全栈其实就是前端不强，后端不行，两边都是半瓶水”。 这个说法其实也很不好，大家时间都是有限的，如果均衡发展天赋，在深度方面是要有所影响的，但全栈有全栈的意义，专栈有专栈的价值，天赋点怎么点是一种取舍。 如果你非要说大部分全栈前端不强，后端不行，你换个说法“大多数开发人员水平都不怎么样都很菜”，这个也都说的通，不过这真没意义，也不是喷点。
至少现在还没看到在异步模型上的突破。我个人不认为Typescript这种语言在异步模型上会有什么突破，微软的东西都逃脱不了.net的标签，c#在异步领域没有突破，Typescript也不可能，希望我有一天被打脸，微软能弄出个原生支持actor模型的语言。
不同语言之间的沟通成本控制在于接口的设计是否合理，前端用Typescript写的代码与后端用Typescript写的代码之间就没有沟通成本么？如果接口协议定好了，我们需要关心前端是Typescript写的还是其他语言写的么？我们需要关心后端是Typescript写的还是go写的，或者其他什么语言写的么？
我想一般情况下，一家公司的一个项目的后端语言最好是尽量统一的，即便不统一也会通过良好的接口设计来消除语言间的沟通成本，这个道理就如我们用javascript写的代码去访问redis，我们会因为redis是C写得就觉得增加了沟通成本么？
大家其实心里很清楚，这个项目如果没有异步模型，模块，包管理方面的突破，跟nodejs比没有任何优势，跟go比增加了包裹层，生态不确定。大家关注这个项目，不过是因为nodejs的创始人而已。
全栈开发我没反对，我本身自己就前后端都做（我深刻的意识到自己前后端都不精通，只是属于能干活而已，这使我更加渴望与专业强悍的前端共事，不管是开发效率，还是开发经验，专业是不可替代的。我自己写的前端代码，碰到个坑，可能需要半天来解决，但专业的前端已经被类似的坑得不知道多少回了，已经天生免疫类似的坑，你认为专业的合适还是我这种半瓶水合适呢？）。但我反对拿全栈做卖点，前后端统一语言就全栈了?前后端的知识体系的差异是靠语言就能抹平的？
@coordcn js 不支持 actor （浏览器支持分布式？搞笑？nodejs 支持，猴年马月？）所以 ts 估计这辈子都不会支持。 希望得到一波真香警告，哈哈。
专业人做专业事，这倒是真的，在理。
我以为 ts 的 runtime 会是微软先推出,没想到居然是 Node 之父 个人还是比较看好这个项目,ts写起来真的很爽,难就难在补全JavaScript的生态过来
@coordcn "不同语言之间的沟通成本控制在于接口的设计是否合理，前端用Typescript写的代码与后端用Typescript写的代码之间就没有沟通成本么？如果接口协议定好了，我们需要关心前端是Typescript写的还是其他语言写的么？我们需要关心后端是Typescript写的还是go写的，或者其他什么语言写的么？" 前端后端都用typescript 写，还真有便利性的，真的融合的很好，大家可以关注下nestjs. 借助于 swagger 能实现类似原来websevice 的发现生成代理类的功能，这样前端写代码，借助于typescript ，可以直接呼出后端的方法签名，这个开发体验是很好的。 如果换别的语言，要熟悉的还真要多挺多的。
nestjs的做的工作其他语言也能实现吧，swagger只能服务于Typscript么？只是你选择了Typescript，所以你才会觉得方便。况且你也没说明为什么前后端统一语言，可以提高开发效率，整个效率的提升是要跟其他语言比较才有实际的意义。比如一个搞java的恐怕不会觉得nestjs加swagger能够促进效率，他们反而会觉得手上的工具更加高效，类似的东西，java成熟得多，为什么要转nestjs呢？
支持actor的语言太多了，但Javascript支持估计是遥遥无期了，浏览器没有分布式的需求。nodejs受限于javascript，javascript受限于浏览器，死循环。。。
原生支持，真不是某个开源库就能解决得了的，c#微软官方和开源社区都有actor的解决方案，你会认为c#支持actor了么？语言内在的东西，依靠外部库来模拟并不能解决根本问题，编程思想上的抽象不可能如原生支持那么纯正。
