本文首发于知乎,各位可以通过点击文章下方的阅读原来来访问原文地址
近日(6月3日),nodeJS的作者——Ry(Ryan Dahl)在JS Conf Berlin上做了一个题为 【10 THINGS I REGRET ABOUT NODE.JS】的演讲(后来又更名为 Node的设计失误(DESIGN MISTAKES IN NODE)。。),总结了自己在node设计中的失误,其中列举了他对NodeJS感到后悔的7件事(说好的10件事呢……)。
Twitter网友的漫画总结
以下内容根据Ry的ppt内容翻译和总结而来。(如果翻译有误,请指正……)
对于NodeJS感到后悔的7件事
◇没有坚持使用Promise
我在2009年6月把Promise加到了Node中,但是又非常愚蠢的在2010年2月把移除去了。Promise是async/await的必要抽象基础。如果在Node中是统一用Promise的话,我们可以快速交付出标准化和async/await的代码。而今天很多异步API因为上面的问题而老化严重。
◇安全问题
V8引擎本身是一个很安全的沙箱。如果我对如何维护某些确定的应用程序有更多的想法,Node可能会有一些很好的安全保证,在任何其他语言中都不可用。
◇构建系统(GYP)
构建一直很难,并且还十分重要。一开始V8引擎(如Chrome)使用GYP,于是我让Node开始使用GYP。后来Chrome抛弃了GYP转而使用GN,使得Node成为了GYP的唯一用户。GYP也不是一个丑陋的内部界面 - 它暴露给任何试图绑定到V8人。继续使用GYP也许是Node内核的最大失败点。与其指导用户将C ++绑定写入V8,我应该提供一个核心外部函数接口(FFI)。
◇package.json
NPM的Isaac发明了package.json。我通过允许Node的require()来检查package.json文件使得它可以获得应用的主入口。最终,我将NPM包含在Node发行版中,这使得它成为了现实意义上的标准。不幸的是,出现了一个中心化(甚至是私有的)的模块管理仓库。
加载一个模板并不是明确的,因为有太多地方定义他了
允许package.json产生了“模块”作为文件目录的概念。这不是绝对必要的抽象 - 也不是网络上存在的抽象。package.json现在包含各种不必要的信息。
License?库? 描述?太多不必要的信息。
如果导入时仅使用相关文件和URL,则路径将定义版本。 没有必要列出依赖关系。
◇node_modules
它极大地使模块分辨率算法复杂化。
默认情况下还是很好的,但实际情况中如果使用$ NODE_PATH环境变量,会让情况变得十分复杂。
它偏离了浏览器语义。
这是我的错,我很抱歉。
不幸的是,现在不可能撤销。
node_modules是整个宇宙最重的物质……
◇加载模块时没有对应的扩展js文件
◇index.js
总结:
我对Node的问题几乎完全在于它如何管理用户代码。
与早期关注均衡I / O的情况相反,模块系统本质上是事后考虑的。 考虑到这一点,那么我在早期阶段就可以做的更好......
Deno的目标
◇目标1:安全性
利用JavaScript是安全沙箱的事实。
不允许将任意本地函数绑定到V8中
◇目标2:简化模块系统
◇目标3:内置TypeScript编译器
◇目标4:以最少的链接来加载一个可执行文件
◇目标5:充分利用2018
通过将带有Parcel的节点模块编译为捆绑包来引导运行时。
(这是对Node必须做的大量简化。)
原生代码已经很多不错的基础框架。
◇目前6:其他
DENO,它才诞生一个月,目前非常的不可用。但目前为止,我仍然很高兴设计了它。