前端框架Svelte放弃TypeScript，回归JavaScript

出品 | OSC开源社区（ID：oschina2013)

根据 Svelte repo 中 “TS to JSDoc Conversion” PR 的描述，Svelte 团队将会从目前使用的 TypeScript 迁移到 JSDoc。

前端 UI 框架 Svelte 创始人 Rich Harris 在推特的回复印证了这一消息。他表示这个决定没有改变 Svelte 的类型安全。

负责 Svelte 编译器的开发者则说道，改用 JSDoc 后，代码不需要编译构建即可进行调试 —— 简化了编译器的开发工作。毕竟目前的调试工作比较复杂，需要使用构建步骤进行调试。

另外，使用 JSDoc 不会影响编译器的开发安全，因为它的类型几乎等同于 TypeScript，依然可以使用 tsc 编译器检查类型。

当然，Svelte 开发者（不是编译器开发者）仍会像现在一样获得类型定义文件。因此对于 Svelte 开发者来说，在类型方面不会有任何变化。

Svelte 不是第一个放弃 TypeScript 的前端框架。早在 2020 年，Deno 就迁移了一部分內部 TypeScript 代码到 JavaScript，以减少构建时间。当时 Deno 团队计划删除所有内部代码构建时的 TS 类型检查与捆绑。

对此，Deno 团队给出的理由是：

• 在变更文件时，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 应用程序）则将深受其害。

===广告分割线===

如果你也正在经历 TypeScript 带来的“痛苦”，并且内心如下：

本文文字及图片出自 OSC开源社区

你也许感兴趣的：

• “再见了，TypeScript！”，Ruby on Rails 之父 DHH 也因“类型”遭劝退
• “TypeScript不值得！”前端框架Svelte作者宣布重构代码，反向迁移到JavaScript引争议
• 一文带你了解 TypeScript 泛型
• 我踩过了 TypeScript 的坑，只想告诉你快来
• 花了四年迁移到 TypeScript，我们总结出了这些经验教训
• Python之父是如何从TypeScript“抄”设计想法的
• 前端程序员需要知道的几个概念：ECMA5Script 、ECMAScript6、TypeScript
• 关于静态类型令人震惊的秘密
• Vue 3是最佳选择吗? 耗时两周从Vue 2迁移到Svelte后：代码执行更快、体验更佳
• 具有魔法的 H.264