7個拒絕使用TypeScript的壞藉口

譯者按： 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 框架的使用有兩個明顯的階段。由於框架的流行首先有一個快速的上升期，而後當開發者接觸到其它新的技術後，慢慢的平穩的降低。整個週期也就幾年的時間。

你自己處於一個快速迭代的行業，而你開發的項目能夠從某些特定的技術中受益。儘管 一、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

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了9億+錯誤事件，獲得了Google、360、金山軟件、百姓網等衆多知名用戶的承認。歡迎免費試用！

版權聲明

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