deno跟node 的也性能差不多啊，为啥要发明个轮子出来？
14 回复
nodejs 的坑已经填不了了 干脆不填了，另开一个小号。
- 更好的开发体验
- 更安全的运行时
- 兼容 Web 标准
往后甚至可能支持交叉编译，运行时跟项目打包进一个可执行文件，部署就这么简单。让 node_modules/package.json 去见鬼
等着真香吧
- node.js 有些坑是不好填的。 比如 node-gyp 这个大坑~ 比如 package.json 又比如你现在想打包二进制文件，虽然有插件能实现，但很不好用 …
- typescript 一直以来缺乏一个 runtime 。
说几点自己的看法：
- 从性能和 runtime 角度来说，未来 v8 引擎直接执行 ast 更有前途（目前只是个提案）。
- deno 正式版发布后 甚至3-5年都很难有生态。
- 会有些 ts 框架同时支持 node 和 deno ，这是很好的过渡方式。
@Gitforxuyang 不同的东西，也不是替代品。 ts 前端开发很普遍，而且泛型，装饰器都有支持，完全面向对象的语言。 go 面向对象方面弱很多了。 目前go 做虚拟化和云计算的多一些
怎么说呢？deno我觉得不算是下一代，但是也确实解决了很多node遗留问题。 我认为有以下几点：
对于普通开发者来说：
- node有很多独有的全局变量，这对移植到浏览器或者js的沙盒环境增加了一些障碍，而deno都是从deno导入进来的，更有利于移植
- deno同时有更多的安全选项，虽然我觉得没多大用，但至少能提醒开发者什么应用使用了什么权限
- 其次就是所谓的非中心化的包使用，像go一样可以直接用http的包，这样能让使用者潜移默化的减少些包嵌包所导致的黑洞问题的可能
- 使用ts同时不强制使用强类型ts，但这却有助于使使用者在语法上更接近于新的js草案
其次对于deno开发者来说：
- 使用gn比node-gyp编译要快很多，给开发者省不少时间
- deno使用rpc调用，不像node和v8代码杂合的那么多，这样v8的升级改动对deno的影响就会小很多
不过半年多没看node和deno了，且node每个版本都有很大变化，这个理解可能还停留在半年多前，但偏差也应该不会太大。
