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

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

負(fù)責(zé) Svelte 編譯器的開發(fā)者則說道，改用 JSDoc 后，代碼不需要編譯構(gòu)建即可進(jìn)行調(diào)試 —— 簡化了編譯器的開發(fā)工作。畢竟目前的調(diào)試工作比較復(fù)雜，需要使用構(gòu)建步驟進(jìn)行調(diào)試。 另外，使用 JSDoc 不會(huì)影響編譯器的開發(fā)安全，因?yàn)樗念愋蛶缀醯韧?TypeScript，依然可以使用 tsc 編譯器檢查類型。

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

對此，Deno 團(tuán)隊(duì)給出的理由是：

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

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

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

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

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

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

審核編輯 ：李倩