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 代码片段拆分为较小的代码片段。
本文分享自微信公众号 - 前端研究所（WEBqdyjs）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。