類型系統-前端進化的里程碑

大半夜的JavaScript Weekly發來賀電：TypeScript 2.0 Final Released！

沒錯，繼Angular2發佈以後，TypeScript今天也發佈了2.0版本，這不由讓我浮想一番。若是要說TS和JS最明顯的差異，我想必定是Type System，因此今天咱們就聊聊類型系統在前端發展歷程中，到底扮演了怎樣的角色。

歷史鬥爭

若是要你把PV上百萬級別的Web Application用一門在10天內擼出來的編程語言來開發，我想你確定不會放心的。然而事實上咱們如今都是這樣乾的，JS已經成爲了最流行的編程語言。JS如今所承擔的使命已經徹底超出了當年設計的初衷，雖然TC39一直在填坑，而且發展到現在的ES6已經至關成熟了，但仍然留下了一些歷史包袱，並不能改變這是一門動態弱類型腳本語言的實質。

所以在前端工程化不斷壯大的過程當中，爲了不踩坑，人類同JS最佳編碼實踐方式展開了曠日持久的戰爭。

最開始，你們都只是取其精華，去其糟粕，如《JavaScript語言精粹》一書所說：大家只須要用我說的就行了，其餘的垃圾都不要學，而且千萬不要在項目裏面用。

通常狀況下每一個公司都會出一套最佳實踐的編碼規範，程序員須要統一代碼風格，按約定編寫代碼。但規範的約束力很低，結果在項目趕着上線的狀況下仍是寫出了翔同樣的代碼，因此更好的方式是用工具來規範代碼，發現一些潛在問題，經過工具來強制約定編碼。好比JSLint，JSHint，以及ESLint，都是設定了一系列編碼約定，讓你避免寫出一些糟糕的代碼。

另一種思路，就是拋棄使用JS做爲開發語言，或者只是把他當成「JVM」,而後採用另一種設計更加嚴謹，不容易採坑的語言來編程，好比CoffeeScript和TypeScript,開發完後再轉譯成JS來運行。

若是以爲這種方式過於激進，那麼能夠採用漸進的方式，好比Flow。Flow能夠在開發時對代碼進行靜態類型分析，用寫強類型的方式來寫弱類型的JS。實質上這有不少好處：

1. 強制聲明類型，IDE和編輯器能夠經過靜態類型分析發現代碼隱藏缺陷，同時也可以提供更強大的自動補全，智能代碼提示和糾錯，達到Java/C++級別的開發體驗。

2. 可避免類型隱式轉換帶來的消耗，提升運行效率。實際上JS引擎在運行時很大的開銷都花在類型分析上。

3. 可讀性/可維護性加強。一眼就能看出這個變量是String仍是Number，代碼維護也更清晰，而且經過註釋工具生成的代碼註釋也會更加詳細，後面換人維護時也更容易上手。

這些優點，其實都是類型系統所帶來的強類型語言所具備的開發優點，不管是在開發體驗仍是後期項目維護上，都要優於目前的JavaScript。

接下來，咱們就以漸進的方式，來感覺一下類型系統帶給咱們的好處。

類型系統

Flow.js

不少狀況下咱們都是在維護項目，不可能爲了增長類型檢查來修改老的項目代碼。Flow能夠在不修改代碼的狀況下，經過註釋的方式來進行靜態類型分析，這爲咱們提供了一個很好的過渡方式。你能夠隨時在任一個項目裏面集成Flow。

/*
* @flow 
* 只須要在文件頭部添加flow註釋，Flow就會認爲這個文件須要靜態分析並檢查
*/

function foo(x) {
  return x * 10;
}

// 這樣調用Flow就會給出錯誤提示：string和number類型不兼容
foo('Hello, world!');

這種無侵入式的集成，能夠檢測出一些比較低級的錯誤，若是要支持更多強大的分析，就須要寫侵入代碼了，好比手動類型註釋：

/* 
* @flow 
* var : [type] 指定變量類型
*/

function add(num1: number, num2: number): number {
  return num1 + num2;
}

// 這樣調用就會報錯，由於參數2已經被聲明爲number了
var x: number = add(3, '0');

這樣的代碼是不能直接運行的，仍是須要Flow工具轉譯成原生JS才能執行。這種方式就更適合新的項目，一旦新項目直接集成了Flow套餐，就能夠直接使用Flow支持的更多功能，而且配合IDE給出更好的開發體驗。

以Mac下的VSC爲例，首先安裝本地Flow環境：

brew update
brew install flow

而後在VSC中安裝啓用vscode-flow插件, ⌘+' 打開用戶配置，禁用VSC自帶的JavaScript校驗功能(設置javascript.validate.enable爲 false)，並設置好flow的安裝目錄：

剩下的套路就跟Babel，ESLint同樣了，在項目根目錄下面創建一個.flowconfig文件，配置一些校驗規則：

vscode-flow插件檢測到.flowconfig配置後就會啓動flow服務去實時分析項目代碼，當你開發的時候就能感覺到比原生編輯器更增強大的自動補全和智能提示了。好比當你require一個util模塊時，flow能分析出util模塊內結構，而且當你調用util方法不當時給出提示：

以上只是介紹簡單流程，而且仍是無侵入式的校驗，若是再加上手動類型聲明的話，還能提供更多功能。

TypeScript

TS的作法更完全，若是有一個全新的項目能夠自由選擇技術方案的話，我必定會選TypeScript而不是Flow.js。惋惜的是，在公司裏面大部分時候都依賴公司自身的技術體系，在作技術選型的時候都要依賴團隊的技術棧。就好比你們都用ES6，你選擇TypeScript，那麼以後別人來維護你的代碼成本就很是高，除非你能煽動整個團隊，整個集團使用：）通常狀況下這是不可能的，我想這也是TS難以普及的重要緣由。

可是，這並不妨礙TypeScript成爲一門優雅的前端開發語言。ES6有的它都有，ES6沒有他也有（泛型/枚舉/類型推導等只有強類型語言纔有的一些特性），而這些特性偏偏更加適合日益壯大的工程化的前端，適合編寫出可維護性代碼。再配合微軟自家的VSC，開發體驗妥妥的：

至於TypeScript 2.0帶來了哪些新特性，請直接戳GitHub：
https://github.com/Microsoft/...

將來趨勢

前幾日GitHub 發佈了2016開源報告，JavaScript衆望所歸的榮登榜首，讓衆前端激動不已：

然而讓我意外的不是排在第一的JavaScript，而是最後的TypeScript：

看這增加趨勢，微軟是要協TypeScript在開源之路上越走越遠了。

私認爲，不管最後是否是TypeScript，類型系統都帶來了更好的開發體驗，代碼質量，代碼可讀性和可維護性，這正是一個大型或長期項目所必須的，也是如今和將來的前端工程所須要的。因此實在是沒有不學的理由，若是你以爲TypeScript像極了C#更適合後端程序員，那麼學習它或許是你邁向全棧的一小步哈哈。