日前Deno官方公布的一份文档指出，出于对当前环境的实际考虑，Deno将停止在内部代码中继续使用TypeScript。文档中提到的问题涉及TypeScript编译时间、结构以及代码组织方式等。未来，Deno项目将使用纯JavaScript编写内部代码。

TypeScript给Deno带来的问题

在使用TypeScript编写内部代码时，Deno团队遇到了以下几个现实问题：

在变更文件时，TypeScript往往需要几分钟的编译时间，这就导致连续编译过程变得非常缓慢；
在创建Deno可执行文件以及面向用户的API源文件时，TypeScript结构会引发一系列运行时性能问题；
TypeScript本身对于Deno代码的组织工作毫无帮助，反而增强了代码组织负担。Deno团队提出的一大现实问题，是TypeScript会在两个位置复制相互独立的Body类；
由于TypeScript编译器无法帮助开发者生成d.ts文件，内部代码与运行时TypeScript声明必须以手动方式保持同步；
他们维护着两台TS编译器主机：一台用于内部Deno代码，另一台用于外部用户代码，但二者的作用其实非常相似。

在内部Deno代码中移除TypeScript

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

值得一提的是，Deno将仅在内部Deno代码中停用TypeScript：Deno用户代码中的TypeScript部分仍将保留，类型检查自然也将一同存在。

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

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

关注Deno停止使用TypeScript的更多详细信息

感兴趣的朋友可以点击此处，了解Deno项目团队在移除TypeScript并转而使用JavaScript方面的完整讨论。Ryan Dahl及其合作者在其中全面探讨了当前问题、解决方案以及实现途径。

原文链接：

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

创作场景

Deno 内部代码将停用 TypeScript，并公布五项具体理由