前端框架Svelte放弃TypeScript，JS赢！

原副标题：后端架构Svelte舍弃TypeScript，JS赢！

公司出品 | OSC开放源码街道社区（ID：oschina2013)

依照 Svelte repo 中 “TS to JSDoc Conversion”PR 的叙述，Svelte 项目组Sonbhadra从现阶段采用的 Type 北迁到 JSDoc。

后端 UI 架构 Svelte 创办人 Rich Harris 在twitter的佐证了这一最新消息。他则表示那个下定决心没发生改变 Svelte 的类别安全可靠。

负责管理 Svelte C++的合作开发人员则写道，转用 JSDoc 后，标识符不须要校对构筑方可展开增容 —— 精简了C++的合作开发组织工作。即便现阶段的增容组织工作非常复杂，须要采用构筑关键步骤展开增容。

除此之外，采用 JSDoc 不能负面影响C++的合作开发安全可靠，即使它的类别基本上等同 Type，仍然能采用 tsc C++检查和类别。

总之，Svelte 合作开发人员（并非C++合作开发人员）仍会像那时那样赢得类别定义文档。因而对 Svelte 合作开发人员而言，在类别各方面不能有任何人变动。

Svelte 并非第二个舍弃 Type 的后端架构。早在 2020 年，Deno 就北迁了一小部分成格 Type 标识符到 Java，以增加构筑时间。当时 Deno 团队计划删除所有内部标识符构筑时的 TS 类别检查和与捆绑。

对此，Deno 项目组给出的理由是：

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

总结就是 增加构筑时间、 降低发布的标识符体积、 增加编写的标识符量。

要注意的是，当时 Deno 仅在内部标识符中停用 Type，Deno 用户标识符中的 Type 部分仍将保留，类别检查和自然也将并存。

从这些案例能看出，虽然 Type 常被视为 Java 的改进版本，但问题也许没那么简单。与任何人其他语言那样，Type 也有自己的缺陷。其最重要的问题之一，在于缓慢的校对速度。在从纯 Java 转换至 Type 时，小型项目可能校对变慢的问题还不算严重，但大型项目（例如复杂的 React 应用程序）则将深受其害。

===广告分割线===

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