是時候再給TypeScript一次機會了【譯】

• 原文地址：It』s time to give TypeScript another chance
• 作者：Jason Dreyzehne
• 翻譯人：李紹懿

自2012年起，TypeScript成為了一些相對結構化語言（像 C++ 或者 Java）的程序員轉入JavaScript的一個流行的選擇。但與此同時，它也受到了大量JS世界「原住民」們的無視。

你可能已經聽說了Angular團隊最近為Angular 2 切換到了TypeScript。其他很多團隊諸如 RxJS、Ionic、 Cycle.js、 Blueprint、 Dojo、 NativeScript、 Plottable也這麼做了。

倘若你已經接觸 JavaScript/Node.js 有一段時間了，你很可能會認為上面這些項目的老大腦子進水了。或者他們可能已經被微軟收買了。??

有類型的JavaScript？

對於剛接觸這個討論的人來說，理解JavaScript世界對類型的厭惡是很重要的。除了JS的便攜性以外，簡單也是JS之所以流行的一個重要因素。

「對於黑客來說，一門語言需要擅長編寫各種他們想要的程序才夠迷人。這意味著，它語言要擅長寫一次性的程序。」— ?Paul Graham （譯者註：Paul Graham 是黑客與畫家的作者，這段話在《Being Popular》這篇文章中提到過）

對於選擇JavaScript作為工具的開發者來說，他們這麼做常常是因為JS的靈活性。沒有標準庫、很少的數據結構、無類型，JavaScript開發者在實施一些新想法的時候，不需要花費太多的時間去思考細節。

一些語言諸如C++在程序需要一大堆數據結構和其餘的信息時，可能是和JavaScript差異最明顯的時候。很多JavaScript程序員（特別是上面提到的那種），各種傳統的類、樣板、類型讓他們感到枯燥，而且類型轉換降低了他們的開發效率。

「把你在過度保護編程語言中的疲憊、委屈，和蜷縮著對自由呼吸的渴望統統都交給我吧。」—JavaScript???

透過這個觀點，很容易明白為什麼很多JavaScript用戶對會對帶類型的JavaScript如此抵觸。

這裡有一些見解可能有助於緩解一些恐懼.

TypeScript 是有更好代碼糾錯能力的 JavaScript

有一個可能是最常見的顧慮，那就是認為TypeScript不是純的JavaScript。這種觀點認為：因為TypeScript是一個單獨的語言，所以會被轉譯成一大坨某一天還需要被迫去調試的糟糕代碼。

很多人都對TypeScript是這個印象

TypeScript 除了已被良好測試和廣泛應用之外，還值得注意的是：基於你的配置，TypeScript代碼事實上只會發生很少的「轉譯」（如果有的話）。TypeScript只是帶了一些選項的Javascrip。

TypeScript 就像一個高級的糾錯器，能夠檢查文檔，當代碼沒有按照預定意圖使用時會發出警告。

它為未來使用你代碼的用戶提供了及時的反饋和更好的開發體驗。這同樣也是對新項目很好的測試——如果你的項目值得去檢查糾正來強制遵循編碼規範，你的項目很可能從 TypeScript 中獲得持久的收益。

TypeScript團隊會在今後致力於關注JavaScript。以便當JavaScript加入穩定的特性時，TypeScript 會進行相應的匹配和調整。

TypeScript 消除了運行時開支

另一個常見的錯誤觀念就是 TypeScript 的類型檢查會存在運行時環境中，這回帶來複雜度和性能開支。

事實上，TypeScript 是一種避免運行時類型檢查的好方法。

TypeScript 是一個開發/編譯時的工具 ?— 它把標準的 JavaScript 加入了可選的類型提示，然後在產出時再移除。（它同樣可以把ES6 和 ES7的特性轉譯成現在的標準）。

TypeScript的類型提示給我們帶來了所有類型的優點，然後再讓類型提示消失。

剩下僅存在運行時中關於對象類型的線索，和標準的 JavaScript 特性是一樣的。（例如，當你從原型創建一個新對象時，你可能會用 instanceof 來檢查它的類型）。

令人啼笑皆非的是，因為 JavaScript 並沒有提供標準的開發時類型檢查，很多 JavaScript 類庫重新開發了它們自己的運行時類型檢測系統。

Request類庫中的運行時類型檢查，它為用戶在不正確的使用方法時提供了更好的debug體驗。但它需要在運行時中需要更多的代碼和更多的單元測試用例。代碼片段→

這並不是這些類庫的初衷，但作為好的開發體驗的一部分，保證用戶能在犯錯時能看見清晰可執行的錯誤信息是必要的。

為了這個目標，很多類庫在運行時大量檢查傳入方法的參數類型，然後拋出錯誤讓開發者看見。

這毫無疑問在兩個世界都爛透了。 這些運行時的類型檢查讓重要代碼變得臃腫、可讀性變差、單元測試代碼覆蓋率達到100%的難度提升。

Bcoin通過提供了運行時拋出有用的錯誤信息提升了開發體驗。但運行時的類型檢查加大了維護和測試成本。這要用 TypeScript 來做的話會更高效和有幫助。 代碼片段→

不使用 Typescript 的話，不僅在開發時失去了類型檢查，而且還可能經常把它帶到運行時中。（我希望你能有100%的測試覆蓋率。）

當你使用 TypeScript 時，你給用戶提供了一個更好的開發體驗、減少了了運行時的類型檢查（除非必須的場景，如用戶輸入），讓你的代碼單元測試更容易完全覆蓋。

TypeScript 已由來已久

可能是因為以上提到的原因，當我第一次聽說 TypeScript 時，我跑的遠遠的。而且它是微軟出品，站在了「JavaScript精華」（較少結構）的對立面。

但現在已經不再是2012年了。TypeScript 不是 JavaScript 的 抽象漏洞，TypeScript 項目中有很多頂級的黑客和工程師。（我很欽佩微軟能夠把項目管理得這麼好。）

自從 TypeScript 跟蹤了 ECMAScript，使用 TypeScript 就不是把你的項目鎖在了一門新語言中。 很多人還沒有意識到這一點，所以聽到這種觀點並不罕見：

「維護一個 TypeScript 項目真難。」

這對於我聽起來就像：

「維護一個有代碼檢查糾錯的項目真難。」

如果你的項目出於某種原因要停止從 TypeScript 中收益了，你可以用編譯器跑一下你的項目，用以把所有類型從你的代碼庫中移除。

然後你就回到無類型的 JavaScript 了。

長話短說

TypeScript 最近得到了很大的改進提升。如果你幾年前就聽說 TypeScript 了，但是在那以後卻沒有跟進，現在值得再看一看。

什麼時候用 TypeScript

Angular: 為什麼是 TypeScript?

一個關於Angular團隊到底為什麼要選擇用TypeScript構建Angular 2簡短的技術討論。

所有應該在TypeScript中編寫的JS類庫

一篇為什麼Typescript用構建JS類庫是個好主意的總結，由Cycle.js 的作者、RxJS貢獻者分享。

深入 Typescript—?為什麼是 TypeScript

一篇關於用TypeScript好處的總結。

學習 TypeScript

Typescript教程

一篇 TypeScript 團隊維護的簡短教程。

Typescript設計目標

一篇概括了TypeScript團隊整體設計原則的wiki。

typescript-starter

一個開發JavaScript類庫的腳手架工程。包含了單元測試、文檔生成還有CommonJS和ES6模塊引入（針對Node.js和瀏覽器環境）。

我抱著改變觀念的希望寫了這篇文章。如果有什麼我可以改進這篇文章的想法，請 告訴我

如果你覺得這篇文章有趣的話，請分享並為我點贊?，謝謝閱讀！

推薦閱讀：