为什么德诺将停止使用打字稿

今天，一份文件浮出水面，指出Deno将停止在其内部代码中使用TypeScript，理由是当前环境存在几个问题。提到的问题涉及打字稿编译时间、结构和代码组织等。接下来，Deno将使用纯JavaScript作为其内部代码。

Deno团队目前在使用TypeScript作为其内部代码时遇到的不利情况是：

更改文件时的Tyescript编译时间需要几分钟，这使得连续编译成为一个极其缓慢的过程。

他们在创建实际Deno可执行文件和面向用户的API的源文件中使用的TypeScript结构正在造成运行时性能问题。

TypeScript没有证明自己对组织Deno代码有帮助。相反，德诺团队正在经历相反的效果。提到的问题之一是，它们最终在两个位置产生了重复的独立Body类https://github.com/denoland/deno/issues/4748。

内部代码和运行时类型脚本声明必须手动保持同步，因为类型脚本编译器无助于生成d.ts文件。

他们维护着两个TS编译器主机：一个用于内部Deno代码，另一个用于外部用户代码，尽管两者的目标相似。

Deno团队的目标是消除内部Deno代码的所有构建时TS类型检查和捆绑。他们期待着将所有运行时代码移到单个JavaScript文件中。但是，他们仍将使用附带的d.ts文件来保存类型定义和文档。

值得一提的是，Deno将停止仅对内部Deno代码使用TypeScript：Deno用户代码仍将是TypeScript，因此会检查类型。

虽然TypeScript有时被视为JavaScript的改进版本，但这个案例表明，实际上并非如此。和任何其他语言一样，它也有缺陷。其中一个最重要的问题是它的编译时间很慢。虽然当小项目从纯JavaScript切换到TypeScript时，编译时间可能不会出现很大的峰值，但在像复杂的Reaction应用程序这样的大项目中，这一点会很明显。考虑到其运行时的大小，Deno将停止使用TypeScript也就不足为奇了。

开发期间类型检查的安全性在编译时是有代价的。TypeScript项目有关于如何解决和改进编译时间的大量文档，这不是没有原因的。最有趣的方法之一是使用项目引用，它允许开发人员将一大段打字脚本代码拆分成较小的部分。

关于决定从内部Deno代码中删除TypeScript而改用JavaScript的完整讨论可以在本文档中找到，Ryan Dahl和合作者在其中讨论了问题、其解决方案以及将如何实现该问题。