7個拒絕使用TypeScript的借口

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

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

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權(quán)歸原作者所有，翻譯僅用于學(xué)習(xí)。

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

1. 學(xué)習(xí)曲線過于陡峭

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

它只是在 JavaScript 的基礎(chǔ)上添加了類型系統(tǒng)(TypeScript 是 JavaScript 的超集)，所以它的學(xué)習(xí)曲線會相對平滑。特別是相對于完全切換到不同編程語言來說。
下面是一段 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 語言的一個設(shè)計者 Anders Hejlsberg 說到：“如果你懂得 JavaScript，那么你就已經(jīng)懂得 TypeScript 了?！?稍后，我會介紹如何將現(xiàn)有的項目切換到 TypeScript 去。

2. JavaScript 是標(biāo)準(zhǔn)，TypeScript 不是

當(dāng) TypeScript 在 2012 年誕生的時候就有了類和模塊的概念，標(biāo)準(zhǔn) JavaScript 直到 2015 年都還沒有！

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

3. 破壞了 JavaScript 的動態(tài)性

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

比如下面的 JavaScript 代碼：

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

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

特別是當(dāng)你的項目越大，和類型相關(guān)的 bug 就越可能觸發(fā)。

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

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"
    );
  });
});

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

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"
    );
  });
});

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

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

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

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

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

4. TypeScript 火不過 5 年

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

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

你本身處于一個快速迭代的行業(yè)，而你開發(fā)的項目可以從某些特定的技術(shù)中受益。盡管 1、2 年后，你已經(jīng)切換到其它技術(shù)，但是你當(dāng)時學(xué)到的經(jīng)驗依然值得。

5. TypeScript 沒有社區(qū)驅(qū)動

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

不過，現(xiàn)已不復(fù)當(dāng)年，TypeScript 身后的開發(fā)團隊意識到為了讓語言被廣泛接受，他們需要深入前端開發(fā)社區(qū)，為開發(fā)者提供高質(zhì)量的開發(fā)工具并且接受反饋不斷改進(jìn)。他們不僅僅是把代碼公開然后默默開發(fā)，而是擁抱了一個開放式開發(fā)的方式。

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

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

6. 切換成本過高

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

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

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

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

declare function camelize(s: string): string;

當(dāng)你導(dǎo)入類型聲明文件后，TypeScript 會正確獲取函數(shù)對應(yīng)的類型。

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

npm install --save-dev @types/jasmine

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

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

結(jié)論

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

關(guān)于Fundebug

Fundebug專注于JavaScript、微信小程序、微信小游戲、支付寶小程序、React Native、Node.js和Java實時BUG監(jiān)控。 自從2016年雙十一正式上線，F(xiàn)undebug累計處理了9億+錯誤事件，得到了Google、360、金山軟件、百姓網(wǎng)等眾多知名用戶的認(rèn)可。歡迎免費試用！

版權(quán)聲明

轉(zhuǎn)載時請注明作者Fundebug以及本文地址：

https://blog.fundebug.com/2018/12/26/7-bad-execuses-for-not-using-ts/