原文发布时间: 2020-05-14
译者: hylerrix
备注: 本文遵循 freeCodeCamp 翻译规范, 同时本文会收录在《Deno 钻研之术》的翻译篇中.
备注: 非营利组织 freeCodeCamp.org 自 2014 年成立以来, 以 "帮助人们免费学习编程" 为使命, 创建了大量免费的编程教程, 包括交互式课程, 视频课程, 文章等. 线下开发者社区遍布 160 多个国家, 2000 多个城市. FCC 正在帮助全球数百万人学习编程, 希望让世界上每个人都有机会获得免费的优质的编程教育资源, 成为开发者或者运用编程去解决问题. 搜索关注微信公众号 "freeCodeCamp", 可了解更多信息.
译者序
在为《Deno 钻研之术》引入第一篇翻译文章的时候, 就看到了这篇文章, 那时还觉得驾驭不了, 就重点先写了若干篇入门级别的 Deno 文章.
转眼到 2021 年, 从《Deno 双周刊》第一期继续开启新的一年的 Deno 之旅, 于是就回想起了本文, 觉得可以通过好好阅读本文及相关后, 从另一个角度了解 Deno, 翻译就开始了.
相比前面对文章的直接翻译外, 本文有很多想要记笔记的地方(甚至 "大开眼界" 的地方), 因此独特地开辟本文的 "译者序" 篇章, 来梳理一下原文及其相关视频到底针对 Deno 的另一面, 都讲了什么.
也正如原文所说, 这注定是一篇有争议的文章, 从文章中引入的两个视频中的点踩数都微微大于点赞数, 其评论区都充满着 "火热" 的讨论就能看出多个观点的冲撞. 原文也存在些过度批评的地方, 但是不妨碍下方译文开始后一比一地还原原作者想要表达的观点!
所以, 原作者 Mehul 在原文以及两个视频中到底想要说 Deno 为什么没那么好? 其观点大致梳理如下:
注意: 如果想先看原文的话可以跳过阅读并在之后来看这份简单的总结.
Deno 和 Node 确实有竞争关系, 因为你必须在你的下个项目中作出选择.
Deno 现在所做的成果并不是很多, 大多特性都可以在 Node 生态中较好地解决掉.
URL import 还是一场灾难. NPM 中已经有很多明星项目 "竟然只有一行代码","暗中偷窃用户数据","注入挖矿代码","兼容性出现问题导致很多上游库受影响" 等问题, URL import 本身并不能解决这些问题, 更没有一个像 Node 一样强壮的社区来保证受人信任的依赖库, 也就不会有更多的开发者愿意加入到 Deno 生态中.
由于 TypeScript 是 JavaScript 的超集, 完全可以选择跳过类型验证, 此时推荐新手在 Deno 上直接使用 TypeScript 编程坑会很大, 很可能会出现一堆 any 类型. 在经常性的调试报错下, TypeScript 的学习成本也较高, 很容易写出低质量代码.
TypeScript 并不是直接在 Deno 上跑的, 其实还是变成了 JavaScript 来跑, 何必一定要集成到 Deno 中呢?
安全是一个很难的事情, Deno 宣传自己的 "安全沙箱" 注定要承担很大的责任. Deno 安全沙箱也没有必要, 完全可以用 Docker 等容器或虚拟化技术来支持. 同时, 真正想搞破坏的脚本也会找到自己的方式来规避安全问题.
以当时版本下的 deno --allow-run 运行主进程从而开启的子进程能轻松突破安全沙箱的验证来获得更多权限为例, 发现 Deno 的 "安全沙箱" 并没有所说的那么安全.
Deno 没有必要集成太多工具链 (代码格式化, 测试工具, TypeScript 等等) 于一体, 让各种第三方工具链来一起共建生态的同时, 保证 Deno 本身的专注性并提供更友好的插件支持会很好.
Node 的异步模型并没有被淘汰, promise 和事件侦听器模型也没有被淘汰, 因此不确定 Deno 将如何解决这些没有被淘汰的问题.
未来并不确定会有多少开发者愿意将 NPM 中的成熟库逐渐迁移到 Deno 中.
可以看出, 无论你是 Node 开发者还是 Deno 爱好者, 这些观点都有很多值得思考的地方. 但也有有失偏颇的地方, 比如文中将 Deno 说明为编程语言, 也将 Deno 只发展了两年多的生态直接和建设了十年的 Node 生态作横向对比 --Deno 注定会有自己独特的发展轨迹.
- const httpResponse: any = await getAPIResponse<any>({
- myParams
- })
- // ...
- const someOtherVariable = something() as any
- // ...
- any, any, any
来源: http://www.jianshu.com/p/8968a4d59dbc