雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
日前 Deno 官方公佈的一份文檔指出，出於對當前環境的實際考慮，Deno 將停止在內部代碼中繼續使用 TypeScript。文檔中提到的問題涉及 TypeScript 編譯時間、結構以及代碼組織方式等。未來，Deno 項目將使用純 JavaScript 編寫內部代碼。
TypeScript 給 Deno 帶來的問題
在使用 TypeScript 編寫內部代碼時，Deno 團隊遇到了以下幾個現實問題：
- 在變更文件時，TypeScript 往往需要幾分鐘的編譯時間，這就導致連續編譯過程變得非常緩慢；
- 在創建 Deno 可執行文件以及面向用戶的 API 源文件時，TypeScript 結構會引發一系列運行時性能問題；
- TypeScript 本身對於 Deno 代碼的組織工作毫無幫助，反而增強了代碼組織負擔。Deno 團隊提出的一大現實問題，是 TypeScript 會在兩個位置複製相互獨立的 Body 類；
- 由於 TypeScript 編譯器無法幫助開發者生成 d.ts 文件，內部代碼與運行時 TypeScript 聲明必須以手動方式保持同步；
- 他們維護着兩臺 TS 編譯器主機：一臺用於內部 Deno 代碼，另一臺用於外部用戶代碼，但二者的作用其實非常相似。
在內部 Deno 代碼中移除 TypeScript
Deno 團隊計劃刪除內部 Deno 代碼中的所有構建時 TS 類型檢查與捆綁。團隊打算將所有運行時代碼轉移到同一個 JavaScript 文件當中，但仍將使用隨附的 d.ts 文件保存類型定義與說明文檔。
值得一提的是，Deno 將僅在內部 Deno 代碼中停用 TypeScript：Deno 用戶代碼中的 TypeScript 部分仍將保留，類型檢查自然也將一同存在。
雖然 TypeScript 常被視爲 JavaScript 的改進版本，但此次情況提醒我們問題也許沒那麼簡單。與任何其他語言一樣，TypeScript 也有自己的缺陷。其最重要的問題之一，在於緩慢的編譯速度。在從純 JavaScript 轉換至 TypeScript 時，小型項目可能編譯變慢的問題還不算嚴重，但大型項目（例如複雜的 React 應用程序）則將深受其害。從 Deno 項目的體量出發，停止使用 TypeScript 也算是順理成章。
但這種性能妥協也可以理解，畢竟在開發過程中進行類型檢查，相當於用編譯時長換取安全保障。當然，TypeScript 項目中也提供關於如何解決並縮短編譯時間的大量說明文檔。最有趣的方法之一當數項目引用，意味着開發人員可以將大規模 TypeScript 代碼片段拆分爲較小的代碼片段。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK