7個拒絕使用TypeScript的借口

2019 年 12 月 30 日
筆記

譯者按： TypeScript 學習成本不高，項目切換成本不低，不過還是值得試一試的！

原文：7 bad excuses for not using TypeScript
譯者: Fundebug

本文採用意譯，版權歸原作者所有

自從 6 年前誕生，TypeScript 逐漸被各大型公司接受。也許你有充足的理由說服自己不要使用它，這些都讓你錯失了 TypeScript。在這篇文章中，我會列舉大家為何不選用 TypeScript 的一些原因，比如學習曲線、工具、開發效率、穩定性以及對標準的兼容性。

1. 學習曲線過於陡峭

首先需要強調一點：TypeScript 並不是一個完全嶄新的開發語言。像 CoffeeScript 和 Reason 吸收了 Ruby 和 OCaml 的語法和語義融入到 JavaScript 語言中。TypeScript 從某種程度上說，更加保守。

它只是在 JavaScript 的基礎上添加了類型系統(TypeScript 是 JavaScript 的超集)，所以它的學習曲線會相對平滑。特別是相對於完全切換到不同編程語言來說。下面是一段 TypeScript 代碼：

class Greeter {      greeting: string;        constructor(message: string) {          this.greeting = message;      }        greet() {          return "Hello, " + this.greeting;      }  }

對比用 ES6 編寫的相同功能的代碼：

class Greeter {      constructor(message) {          this.greeting = message;      }        greet() {          return "Hello, " + this.greeting;      }  }

正如 TypeScript 語言的一個設計者 Anders Hejlsberg 說到：「如果你懂得 JavaScript，那麼你就已經懂得 TypeScript 了。」稍後，我會介紹如何將現有的項目切換到 TypeScript 去。

2. JavaScript 是標準，TypeScript 不是

當 TypeScript 在 2012 年誕生的時候就有了類和模塊的概念，標準 JavaScript 直到 2015 年都還沒有！

今天，TypeScript 語言緊隨 ECMAScript 的定義，幾乎實現了Stage 3所有的提案。也就是說，當你在使用 TypeScript 的時候，你其實已經在用最新的 JavaScript。而且感謝 ES3/ES5 編譯器，最終輸出的.js文件即使在舊版本的瀏覽器也不會出問題。

3. 破壞了 JavaScript 的動態性

如果你熟練使用腳本語言工作，你會喜歡它驚人的開發效率。你可以在代碼中隨時修改數據結構，而不必事先聲明。這種自由度，也伴隨着代價。這種動態語言有了 bug 有時候很難搞定，它不會像靜態語言一樣，在編譯的時候有做類型的驗證來保證代碼的正確性。

比如下面的 JavaScript 代碼：

function greeter(person) {      return "Hello, " + person.firstName + " " + person.lastName;  }

通過代碼我們可以判斷 person 參數是一個對象，它有 firstName 和 lastName 兩個屬性。但是我們無法保證在運行時一定是這樣。

特別是當你的項目越大，和類型相關的 bug 就越可能觸發。

為了避免出現問題，我們可以加上很多運行時的驗證，以及單元測試：

function greeter(person) {      if (!person || !person.firstName || !person.lastName) {          throw new Error("invalid arguments");      }        return "Hello, " + person.firstName + " " + person.lastName;  }    // Jasmine spec:  describe("greeter", function() {      it("returns greeting on valid input", function() {          expect(greeter({ firstName: "James", lastName: "Hetfield" })).toEqual(              "Hello, James Hetfield"          );      });        it("throws on invalid input", function() {          expect(() => greeter()).toThrowError("invalid arguments");          expect(() => greeter(5)).toThrowError("invalid arguments");          expect(() => greeter({ firstName: "Jason" })).toThrowError(              "invalid arguments"          );      });  });

但是，這樣的實現方法很累贅，開發者需要在每個函數前面都加上這樣的判斷來保證正確性。換個思路，如果我們給函數的參數加上類型，這個事情不就省去了么。

interface Person {      firstName: string;      lastName: string;  }    function greeter(person: Person) {      return "Hello, " + person.firstName + " " + person.lastName;  }    // Jasmine spec:  describe("greeter", function() {      it("returns greeting", function() {          expect(greeter({ firstName: "James", lastName: "Hetfield" })).toEqual(              "Hello, James Hetfield"          );      });  });

上面的代碼更加簡潔，甚至連測試也只需要考慮代碼的邏輯而不是數據的正確性。

TypeScript 有強大的類型系統來做類型推斷。你並不需要像在 C# 或則 Java 中那樣，顯示的列出數據的類型。下面是一個例子：

let user = { firstName: "James", lastName: "Hetfield" };  console.log(greeter(user));

上面的代碼可以成功編譯。請注意我們並沒有聲明 user 是 Person 類型的。

TypeScript 編譯器並不會強制你必須在所有地方都聲明類型，你可以在正確性和效率上自己做一個權衡。你甚至可以在項目不同的區域自定義類型的嚴格程度。這樣的靈活性超出了以前所有的開發語言。

4. TypeScript 火不過 5 年

沒有人可以確保哪種語言、工具或者框架一定可以持續活躍，特別是在前端這一領域。一個StackOverflow 博客的作者這樣寫道：

在 JavaScript 框架的使用有兩個明顯的階段。因為框架的流行首先有一個快速的上升期，然後當開發者接觸到其它新的技術後，慢慢的平穩的下降。整個周期也就幾年的時間。

你本身處於一個快速迭代的行業，而你開發的項目可以從某些特定的技術中受益。儘管 1、2 年後，你已經切換到其它技術，但是你當時學到的經驗依然值得。

5. TypeScript 沒有社區驅動

TypeScript 由微軟在 2012 年發佈，考慮到公司的形象以及其開發平台，很容易產生「只不過是給.Net 開發者打造的一個 JavaScript 開發玩具而已」的想法。特別是當時只有 Visual Studio 對 TypeScript 有足夠的支持。事實上，TypeScript 的源代碼最開始是發佈在CodePlex上，一個微軟自己的 GitHub。

不過，現已不復當年，TypeScript 身後的開發團隊意識到為了讓語言被廣泛接受，他們需要深入前端開發社區，為開發者提供高質量的開發工具並且接受反饋不斷改進。他們不僅僅是把代碼公開然後默默開發，而是擁抱了一個開放式開發的方式。

在 2014 年，TypeScript 的源代碼移到了GitHub託管。而且整個開發都在 GitHub 上公開透明。他們同時接受外部提交貢獻，包括記錄 bug，提出建議以及提交 pull request。所有的 issue 會定期更新，幾天之內就會有回應。核心團隊發佈了語言的設計理念用來指導團隊不偏離目標並積極吸收社區的建議。他們有一個保持更新的roadmap(基本上每兩個月發佈一次更新)，並記錄重大的更新。

在我寫這篇文章的時候，所有主流的跨平台 IDE 或則編輯器像 Eclipse、Webstorm、Emacs、Vim、Sublime、Atom 和 VS Code 都對 TypeScript 有着很好的支持，要麼是內置的，要麼通過插件。為了和現有的庫和框架交互，核心團隊花了很多時間來創建類型定義文件。另一個值得一提的是編譯器 API 的文檔非常完善，可以很好地構建第三方工具。TypeScript 的開發者團隊也鼓勵開發者在StackOverflow上提出技術問題。

6. 切換成本過高

為了充分發揮 TypeScript 的優勢，你需要花費不少時間來聲明類型並修復編譯錯誤，這會很繁瑣。TypeScript 的創建者們有考慮到原有 JavaScript 項目切換的問題，提供了相應的方案。

根據官方的遷移指導，你可以直接運行 TypeScript 的編譯器。編譯器會拋出一些低層級的 bug，比如沒有 return 語句，代碼塊中有永遠不會執行的代碼。然後，你可以將.js 文件重命名為.ts 文件，然後再處理編譯結果。編譯器默認的選項沒有特別嚴格，你可以開啟更加嚴格的驗證。整個遷移有一個底線：整個過程是相當平滑的，它不會使開發中斷。你可以選擇慢慢將一個項目切換到 TypeScript，或則來個快速的切換(參考:3 天搞定 60 萬行代碼的遷移)。社區還有一個叫做TypeWiz的項目可以自動給代碼添加類型信息。

7. 但是我使用的庫都是基於 JavaScript

為了和現有的 JavaScript 模塊無縫對接，TypeScript 支持類型聲明文件。舉個例子，如果你使用的庫中導出了一個 camelize 的函數，你可以定義一個類型聲明文件並給出如下的定義：

declare function camelize(s: string): string;

當你導入類型聲明文件後，TypeScript 會正確獲取函數對應的類型。

TypeScript 同時也發佈了DefinitelyTyped，這個 repository 包含了所有流行的庫的類型定義文件。在我寫這篇文章的時間點，DefinitelyTyped 已經包含了超過 5000 個 JavaScript 包的類型定義。使用方法非常簡單：

npm install --save-dev @types/jasmine

類型文件會自動被編譯器包含，並且在編輯器中也會有對應的代碼提示。幾乎所有或則大多數你使用的包都已經有對應的類型定義文件了，要麼自身有相應的類型定義文件，要麼在 DefinitelyTyped 可以找到，你只需要下載安裝就好。Slack 的開發團隊分享了他們的經驗：

考慮到代碼維護，我們真的很感謝 TypeScript 強大的生態系統。我們是 React 和 Node/npm 的重度用戶，第三方庫也有對應的類型文件極大方便了開發。很多我們導入的庫已經和 TypeScript 兼容。如果沒有，那麼也可以在 DefinitelyTyped 找到。比如，React 並沒有自帶類型定義，你可以通過npm install @types/react來安裝，無需其他額外操作。

結論

使用靜態類型檢車可以幫助你消除很多 bug，對於一個基於 Node/JavaScript 的項目，TypeScript 是你最好的選擇。對於一個相對小或則試驗性的項目，也許沒有必要。但是，一個大型的項目，TypeScript 絕對值得你嘗試。它帶來的好處遠遠大於它帶來的複雜度。一些大型的公司都開始使用也是最好的證明，比如 Google、Slack、Asana、Ember 等等。希望這篇文章給你啟發，讓你重新燃起對 TypeScript 嘗試的慾望。

版權聲明

轉載時請註明作者 Fundebug以及本文地址： https://blog.fundebug.com/2018/12/26/7-bad-execuses-for-not-using-ts/

您的用戶遇到BUG了嗎？

體驗Demo 免費使用