根據(jù) Svelte repo 中"TS to JSDoc Conversion"PR 的描述，Svelte 團隊將會從目前使用的 TypeScript 遷移到 JSDoc。

前端 UI 框架 Svelte 創(chuàng)始人 Rich Harris 在推特的回復(fù)印證了這一消息。他表示這個決定沒有改變 Svelte 的類型安全。

負(fù)責(zé) Svelte 編譯器的開發(fā)者則說道，改用 JSDoc 后，代碼不需要編譯構(gòu)建即可進行調(diào)試 —— 簡化了編譯器的開發(fā)工作。畢竟目前的調(diào)試工作比較復(fù)雜，需要使用構(gòu)建步驟進行調(diào)試。 另外，使用 JSDoc 不會影響編譯器的開發(fā)安全，因為它的類型幾乎等同于 TypeScript，依然可以使用 tsc 編譯器檢查類型。

當(dāng)然，Svelte 開發(fā)者（不是編譯器開發(fā)者）仍會像現(xiàn)在一樣獲得類型定義文件。因此對于 Svelte 開發(fā)者來說，在類型方面不會有任何變化。 Svelte 不是第一個放棄 TypeScript 的前端框架。早在 2020 年，Deno就遷移了一部分內(nèi)部 TypeScript 代碼到 JavaScript，以減少構(gòu)建時間。當(dāng)時Deno 團隊計劃刪除所有內(nèi)部代碼構(gòu)建時的 TS 類型檢查與捆綁。

對此，Deno 團隊給出的理由是：

在變更文件時，TypeScript 往往需要幾分鐘的編譯時間，這導(dǎo)致連續(xù)編譯過程變得非常緩慢；

在創(chuàng)建 Deno 可執(zhí)行文件以及面向用戶的 API 源文件時，TypeScript 結(jié)構(gòu)會引發(fā)一系列運行時性能問題；

TypeScript 本身對于 Deno 代碼的組織工作毫無幫助，反而增強了代碼組織負(fù)擔(dān)。Deno 團隊提出的一大現(xiàn)實問題，是 TypeScript 會在兩個位置復(fù)制相互獨立的 Body 類，https://github.com/denoland/deno/issues/4748

由于 TypeScript 編譯器無法幫助開發(fā)者生成 d.ts 文件，內(nèi)部代碼與運行時 TypeScript 聲明必須以手動方式保持同步；

他們維護著兩臺 TS 編譯器主機：一臺用于內(nèi)部 Deno 代碼，另一臺用于外部用戶代碼，但二者的作用其實非常相似。

總結(jié)就是減少構(gòu)建時間、降低發(fā)布的代碼體積、減少編寫的代碼量。 要注意的是，當(dāng)時 Deno 僅在內(nèi)部代碼中停用 TypeScript，Deno 用戶代碼中的 TypeScript 部分仍將保留，類型檢查自然也將并存。 從這些案例可以看出，雖然 TypeScript 常被視為 JavaScript 的改進版本，但問題也許沒那么簡單。與任何其他語言一樣，TypeScript 也有自己的缺陷。其最重要的問題之一，在于緩慢的編譯速度。在從純 JavaScript 轉(zhuǎn)換至 TypeScript 時，小型項目可能編譯變慢的問題還不算嚴(yán)重，但大型項目（例如復(fù)雜的 React 應(yīng)用程序）則將深受其害。

審核編輯 ：李倩