Deno 繼顛覆 Node 之后,又“內部”拒絕了 TypeScript

（給前端大學加星標，提升前端技能.）

轉自：oschina

https://www.oschina.net/news/116620/deno-will-stop-using-typescript

Deno 團隊計劃刪除所有內部代碼構建時的 TS 類型檢查與捆綁。打算將所有運行時代碼轉移到同一個 JavaScript 文件當中，但仍將使用隨附的 d.ts 文件保存類型定義與說明文檔。理由是：

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

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

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

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

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

需注意的是，Deno 將僅在內部代碼中停用 TypeScript，Deno 用戶代碼中的 TypeScript 部分仍將保留，類型檢查自然也將并存。

雖然 TypeScript 常被視為 JavaScript 的改進版本，但此次情況提醒我們問題也許沒那么簡單。與任何其他語言一樣，TypeScript 也有自己的缺陷。其最重要的問題之一，在于緩慢的編譯速度。?在從純 JavaScript 轉換至 TypeScript 時，小型項目可能編譯變慢的問題還不算嚴重，但大型項目（例如復雜的 React 應用程序）則將深受其害。從 Deno 項目的體量出發(fā)，停止使用 TypeScript 也算是順理成章。

但這種性能妥協(xié)也可以理解，畢竟在開發(fā)過程中進行類型檢查，相當于用編譯時長換取安全保障。當然，TypeScript 項目中也提供關于如何解決并縮短編譯時間的大量說明文檔。最有趣的方法之一是項目引用，意味著開發(fā)人員可以將大規(guī)模 TypeScript 代碼片段拆分為較小的代碼片段。

分享前端好文，點亮?在看?