TypeScript 這些年越來越火，可以說是前端工程師的必備技能了，各大框架都基于它實(shí)現(xiàn)。

那么，TypeScript 的出現(xiàn)和爆火是偶然發(fā)生的嗎?其實(shí)不是，類似 TypeScript 這種靜態(tài)類型語言成為主流是必然會發(fā)生的。為什么這么說呢?

讓我們先思考一個問題：類型是什么?

類型具體點(diǎn)來說就是指 number、boolean、string 等基礎(chǔ)類型和 Object、Function 等復(fù)合類型，它們是編程語言提供的對不同內(nèi)容的抽象：

• 不同類型變量占據(jù)的內(nèi)存大小不同：boolean 類型的變量只會分配 1 個字節(jié)的內(nèi)存，而 number 類型的變量則會分配 8 個字節(jié)的內(nèi)存，給變量聲明了不同的類型就代表了會占據(jù)不同的內(nèi)存空間。
• 不同類型變量可做的操作不同：number 類型可以做加減乘除等運(yùn)算，boolean 就不可以，復(fù)合類型中不同類型的對象可用的方法不同，比如 Date 和 RegExp，變量的類型不同代表可以對該變量做的操作就不同。

我們知道了什么是類型，那自然可以想到類型和所做的操作要匹配才行，這就是為什么要做類型檢查。

如果能保證對某種類型只做該類型允許的操作，這就叫做類型安全。比如你對 boolean 做加減乘除，這就是類型不安全，你對 Date 對象調(diào)用 exec 方法，這就是類型不安全。反之，就是類型安全。

所以，類型檢查是為了保證類型安全的。

類型檢查可以在運(yùn)行時做，也可以運(yùn)行之前的編譯期做。這是兩種不同的類型，前者叫做動態(tài)類型檢查，后者叫做靜態(tài)類型檢查。

兩種類型檢查各有優(yōu)缺點(diǎn)。動態(tài)類型檢查 在源碼中不保留類型信息，對某個變量賦什么值、做什么操作都是允許的，寫代碼很靈活。但這也埋下了類型不安全的隱患，比如對 string 做了乘除，對 Date 對象調(diào)用了 exec 方法，這些都是運(yùn)行時才能檢查出來的錯誤。

其中，最常見的錯誤應(yīng)該是 “null is not an object”、“undefined is not a function” 之類的了，寫代碼時沒發(fā)現(xiàn)類型不匹配，到了運(yùn)行的時候才發(fā)現(xiàn)，就會有很多這種報(bào)錯。

所以，動態(tài)類型雖然代碼寫起來簡單，但代碼中很容易藏著一些類型不匹配的隱患。

靜態(tài)類型檢查則是在源碼中保留類型信息，聲明變量要指定類型，對變量做的操作要和類型匹配，會有專門的編譯器在編譯期間做檢查。

靜態(tài)類型給寫代碼增加了一些難度，因?yàn)槟愠艘紤]代碼要表達(dá)的邏輯之外，還要考慮類型邏輯：變量是什么類型的、是不是匹配、要不要做類型轉(zhuǎn)換等。

不過，靜態(tài)類型也消除了類型不安全的隱患，因?yàn)樵诰幾g期間就做了類型檢查，就不會出現(xiàn)對 string 做了乘除，調(diào)用了 Date 的 exec 方法這類問題。

所以，靜態(tài)類型雖然代碼寫起來要考慮的問題多一些，會復(fù)雜一些，但是卻消除了代碼中潛藏類型不安全問題的可能。

知道了動態(tài)類型檢查和靜態(tài)類型檢查的區(qū)別，我們自然可以得出這樣的結(jié)論：

動態(tài)類型只適合簡單的場景，對于大項(xiàng)目卻不太合適，因?yàn)榇a中可能藏著的隱患太多了，萬一線上報(bào)一個類型不匹配的錯誤，那可能就是大問題。

而靜態(tài)類型雖然會增加寫代碼的成本，但是卻能更好的保證代碼的健壯性，減少 Bug 率。

所以，大型項(xiàng)目注定會用靜態(tài)類型語言開發(fā)。

JavaScript 本來是為了瀏覽器的表單驗(yàn)證而設(shè)計(jì)的，所以就設(shè)計(jì)成了動態(tài)類型的，寫代碼比較簡單。

但 JavaScript 也沒想到它后來會被用來開發(fā)各種項(xiàng)目，比如 PC 和移動端的網(wǎng)頁、React Native 跨端 App、小程序、Electron 桌面端、Node.js 服務(wù)端、Node.js 工具鏈等。

開發(fā)各種大型項(xiàng)目的時候，JavaScript 的動態(tài)類型語言的缺點(diǎn)就暴露出來了，bug 率太高了，健壯性很難保證。那自然就有了對靜態(tài)類型的強(qiáng)烈需求，于是 TypeScript 應(yīng)運(yùn)而生。

TypeScript 給 JavaScript 添加了一套靜態(tài)類型系統(tǒng)，從動態(tài)類型語言變成了靜態(tài)類型語言，可以在編譯期間做類型檢查，提前發(fā)現(xiàn)一些類型安全問題。

而且，因?yàn)榇a中添加了靜態(tài)類型，也就可以配合編輯器來實(shí)現(xiàn)更好的提示、重構(gòu)等，這是額外的好處。

所以，TypeScript 的火爆是一個偶然么?不，我覺得是必然，因?yàn)榇笮晚?xiàng)目注定會用靜態(tài)類型語言來開發(fā)。

總結(jié)

類型決定了變量的內(nèi)存大小和可以對它進(jìn)行的操作，保證對什么類型只做什么操作就叫做類型安全，而保證類型安全的方式就是類型檢查。

類型檢查可以在運(yùn)行時做，叫做動態(tài)類型檢查，也可以在編譯時做，叫做靜態(tài)類型檢查。

動態(tài)類型可能藏在代碼里的隱患太多了，bug 率比較高，所以大型項(xiàng)目注定會用靜態(tài)類型語言來開發(fā)。

JavaScript 本身是一門動態(tài)類型語言，因?yàn)楸辉絹碓蕉嗟挠脕黹_發(fā)各種大型項(xiàng)目，所以就有了對靜態(tài)類型的需求。TypeScript 就滿足了這個需求。而且還有額外的更好的提示、更易于重構(gòu)的好處。

所以，TypeScript 的出現(xiàn)和現(xiàn)在的火爆是必然會發(fā)生的。