Deno 继颠覆 Node 之后,又“内部”拒绝了 TypeScript

2020年06月22日

Deno 团队计划删除所有内部代码构建时的 TS 类型检查与捆绑。打算将所有运行时代码转移到同一个 JavaScript 文件当中,但仍将使用随附的 d.ts 文件保存类型定义与说明文档。理由是:

  • 在变更文件时,TypeScript 往往需要几分钟的编译时间,这导致连续编译过程变得非常缓慢;

  • 在创建 Deno 可执行文件以及面向用户的 API 源文件时,TypeScript 结构会引发一系列运行时性能问题;

  • TypeScript 本身对于 Deno 代码的组织工作毫无帮助,反而增强了代码组织负担。Deno 团队提出的一大现实问题,是 TypeScript 会在两个位置复制相互独立的 Body 类,https://github.com/denoland/deno/issues/4748

  • 由于 TypeScript 编译器无法帮助开发者生成 d.ts 文件,内部代码与运行时 TypeScript 声明必须以手动方式保持同步;

  • 他们维护着两台 TS 编译器主机:一台用于内部 Deno 代码,另一台用于外部用户代码,但二者的作用其实非常相似。

需注意的是,Deno 将仅在内部代码中停用 TypeScript,Deno 用户代码中的 TypeScript 部分仍将保留,类型检查自然也将并存。

虽然 TypeScript 常被视为 JavaScript 的改进版本,但此次情况提醒我们问题也许没那么简单。与任何其他语言一样,TypeScript 也有自己的缺陷。其最重要的问题之一,在于缓慢的编译速度。 在从纯 JavaScript 转换至 TypeScript 时,小型项目可能编译变慢的问题还不算严重,但大型项目(例如复杂的 React 应用程序)则将深受其害。从 Deno 项目的体量出发,停止使用 TypeScript 也算是顺理成章。

但这种性能妥协也可以理解,毕竟在开发过程中进行类型检查,相当于用编译时长换取安全保障。当然,TypeScript 项目中也提供关于如何解决并缩短编译时间的大量说明文档。最有趣的方法之一是项目引用,意味着开发人员可以将大规模 TypeScript 代码片段拆分为较小的代码片段。

感兴趣的朋友可以移步 Google 发布的文档,了解 Deno 项目团队在移除 TypeScript 并转而使用 JavaScript 方面的完整讨论

Ryan Dahl 及其合作者在其中全面探讨了当前问题、解决方案以及实现途径。

稿源:https://startfunction.com/deno-will-stop-using-typescript

展开阅读全文
5 收藏
分享
加载中
精彩评论
属实欢乐,开始觉得js是个坑,换ts,等换了ts又发现更大的坑,又换回js,等用了一段时间又发现跟node一样烂到无法维护,又扔了,再搞一个oned,跟闹着玩似的
2020-06-22 17:28
29
举报
没有活路了 webasm将要杀死他们
2020-06-22 16:54
14
举报
前端看了想打人,后端看了内心毫无波澜
2020-06-22 18:11
13
举报
别急,慢慢来,Rust 的坑还没漏出来呢
2020-06-22 18:23
5
举报
我们永远也不可能得到一个完美的工具,node不是,done也不会是。
c++很显然不是的,rust不会是的。
就像我们可能永远都没有机会搞清楚宇宙这块表到底是怎么运行的一样。
但这并不不能阻止人们探索的脚步。现存的法律和政体都有严重缺陷,这正需要人们去探究,去扬弃。
若不出意外,现存所有的科学真理,在几百年后,都将被证伪,今天的真理会成为明天的“地心说”。但是,我们的脚步岂可因此而停止?!若不愿意一直使用汇编,不愿意一直使用诺基亚1600, 讲道理的话,就该无脑支持deno,支持dnoe,doen.....
2020-06-24 03:17
4
举报
最新评论 (35)
累不累啊,闲的蛋疼!
2020-06-28 15:45
0
回复
举报
1.社区需要的是更好的JavaScript及强类型。
2.需要比node-gyp更好的第三方插件机制。
3.需要比node_module更好的机制
2020-06-28 14:02
0
回复
举报
This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
2020-06-28 09:00
1
回复
举报
换成 dart 吧
2020-06-25 16:24
0
回复
举报
我们永远也不可能得到一个完美的工具,node不是,done也不会是。
c++很显然不是的,rust不会是的。
就像我们可能永远都没有机会搞清楚宇宙这块表到底是怎么运行的一样。
但这并不不能阻止人们探索的脚步。现存的法律和政体都有严重缺陷,这正需要人们去探究,去扬弃。
若不出意外,现存所有的科学真理,在几百年后,都将被证伪,今天的真理会成为明天的“地心说”。但是,我们的脚步岂可因此而停止?!若不愿意一直使用汇编,不愿意一直使用诺基亚1600, 讲道理的话,就该无脑支持deno,支持dnoe,doen.....
2020-06-24 03:17
4
回复
举报
webasm谁也杀不死,反而会让众多语言旺盛起来,因为,只要愿意的话,大家都可以编译成webasm。就像那么多语言都可以编译,或者说转译,成js一样。在c语言的世界也有类似情况,新语言nim不是编译成标准c吗?
2020-06-24 03:03
3
回复
举报
我感觉不少人还没有看清楚情况就开喷了。
“内部”,知道这个词在这里是指什么意思吗?
我不少人可能只看了标题,并且没看懂标题。不过,这也是文章作者故意哗众。
“内部”,这里是指“在实现deno内部逻辑的时候”。最终的deno命令是肯定可以执行ts代码的。
不用再解释了吧。
js这么多坑,ts填平了这些坑,并且在上面盖了宾馆,谁用谁知道。
2020-06-24 02:56
4
回复
举报
你窥见了标题党的用意😂
2020-06-24 10:46
0
回复
举报
😂
2020-06-24 10:59
0
回复
举报
看成盖了 殡仪馆
2020-06-29 09:21
0
回复
举报
由于 TypeScript 编译器无法帮助开发者生成 d.ts 文件,内部代码与运行时 TypeScript 声明必须以手动方式保持同步;
???
编译时,不是可以自动生成么...
2020-06-23 23:07
0
回复
举报
如果是UI 界面,那js 主要优势还是开发效率和生态。
如果是游戏引擎和一些特殊应用,wasm 优势明显。
2020-06-23 20:19
0
回复
举报
edon在路上了
2020-06-23 16:52
0
回复
举报
更多评论
35 评论
5 收藏
分享
返回顶部
顶部