，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发!

　　本文将重点介绍两个前端领域的明星项目 Deno 和 Svelte，因为它们本身框代码已经从 TypeScript 迁移到 JavaScript 从而成功引起了开发者的注意。话不多说，直接开始！

　　TypeScript 是 2022 年排名增长最快的语言，并且在过去五年使用率显著增长，从 2017 年的 12% 上升到 2022 年的 34%。作为 JavaScript 的主要替代形式之一，TypeScript 非常受欢迎，尤其是在大型 JavaScript 开发人员中，这一切都得益于它的项目可扩展性、协作性和代码可维护性。

　　当然，有为 TypeScript 喝彩的，也有唱衰 TypeScript 的，本文将重点介绍两个前端领域的明星项目 Deno 和 Svelte，因为它们本身框代码已经从 TypeScript 迁移到 JavaScript 从而成功引起了开发者的注意。

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

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

　　TypeScript 并没有证明有助于 Deno 代码组织，甚至适得其反。 比如：在两个位置有重复的独立 Body 类

　　内部代码和运行时 TypeScript 声明必须手动保持同步，因为 TypeScript 编译器对生成 d.ts 文件没有帮助

　　需要维护两台 TS 编译器主机：一台用于内部 Deno 代码，另一台用于外部用户代码，尽管目的相同。

　　Deno 团队的目标是删除所有构建时 TS 类型检查和内部 Deno 代码的打包，期待将所有运行时代码移动到一个 JavaScript 文件中。 但是，Deno 仍将使用配套的 d.ts 文件来保存类型定义和文档。

　　虽然 TypeScript 有时被视为 JavaScript 的改进版本，但事实并非总是如此， TypeScript 语言也有先天缺陷， 比如：最重要的编译时间。

　　虽然小型项目在从纯 JavaScript 切换到 TypeScript 时可能不会看到编译时间的巨大峰值，但在大型项目（如复杂的 React 应用程序）中却会很明显。 鉴于 Deno 运行时的庞大规模，Deno 停止使用 TypeScript 也就不足为奇了。

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

　　Svelte 是一种构建 Web 应用程序的新方法。它是一个编译器，可以获取声明性组件并将它们转换为高效的 JavaScript，从而轻松地更新 DOM。目前 Svelte 已经通过 MIT 协议开源，在 Github 上狂揽 66.9K 的 star、3.3k 的 fork、超过 167k 的项目依赖量，代码贡献者 600+，妥妥的前端佼佼者。

　　Loraine Lawson 感慨自己已经做了十年的开发，从来没有遇到过 JavaScript 的松散类型带来的诸多问题。 而使用 TypeScript，需要用 15 分钟编写代码，但可能需要 2 小时试图安抚静态类型的神 。这也就很容易理解，为什么 Svelte 要放弃 TypeScript 而拥抱 JavaScript 了。

　　本文主要和大家介绍两个前端领域的明星项目 Deno 和 Svelte，因为它们本身框代码已经从 TypeScript 迁移到 JavaScript 从而成功引起了开发者的注意。关于Deno vs. Svelte，文章并没有过多展开，如果有兴趣，可以在我的主页继续阅读，同时文末的参考资料提供了大量优秀文档以供学习。最后，欢迎大家点赞、评论、转发、收藏！