根據 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 應用程序）則將深受其害。

審核編輯 ：李倩