你是否經常在文章中見到 “你還沒有用TypeScript麼，都2020年了！” 這樣的標語？今天我們就來探究一下TypeScript的優缺點。
此篇文章適用於沒接觸過TypeScript的人、僅讀過文檔但無實際項目操作的人，筆者希望藉此文章可以給大家提供一個思路，便於以上兩種類型的讀者做出選擇。如果你是TypeScript老鳥，這篇文章可能並不適用於你，但是歡迎閱讀並一起討論。
什麼是TypeScript？
TypeScript是一種由微軟開發的開源、跨平臺的編程語言。它是JavaScript的超集，最終會被編譯爲JavaScript代碼。
TypeScript添加了可選的靜態類型系統和很多尚未正式發佈的ECMAScript新特性。
TypeScript支持任意瀏覽器，任意環境，任意系統並且是開源的。
先列優缺點:
優點：
靜態類型
方便閱讀
減少bug
社區活躍
缺點：
學習成本
開發效率的降低
部分三方庫的兼容
需要編譯
靜態類型
我們都知道，JavaScript是一個弱類型，且是動態類型的腳本語言。筆者大學期間第一次接觸JavaScript時簡直驚呆了，這也太幸福了吧！什麼變量都可以var一下，變量還可以隨便賦值，函數的返回值類型？我再也不用關心這些亂七八糟的東西了，這纔是語言應該有的樣子啊！
但是隨着做過的項目越來越多，這裏要加一個類型判斷，那裏也要進行一次類型轉換，我漸漸意識到，這個問題不是看到的那樣簡單，想到這裏，我不禁把目光投向了“幸福的罪魁禍首”：“靜態類型”。
你是否經常要寫這種類似的代碼？
const data = typeof params === 'object'
? params.data
: JSON.parse(params).data;
if (typeof unix === 'string') {
unix = parseInt(unix);
}
試想一下：
你花了一下午的時間，搞出來一個自認爲完美的函數。
然後小明1號拿去調用一下，程序崩潰了。
你查了一下原因：啊，原來是參數的類型傳錯了，趕緊補文檔補註釋說明一下。
然後小明2號拿去調用了一下，程序崩潰了。
你查了一下原因：啊，原來是參數的類型傳錯了，你趕緊叮囑大家使用時看文檔。
然後小明3號拿去調用了一下，程序崩潰了。
你查了一下原因：啊，參數類型沒錯，但是參數對象裏面的值的類型傳錯了，你???@#&!!!...只能寫上一堆判斷和轉換，讓自己的程序更“健壯”。
上面的例子比較極端，但是我們確確實實在經常遇到，那如果js是靜態類型的會是什麼樣子呢？
你花了一下午的時間，搞出來一個自認爲完美的函數。
然後小明1號拿去調用一下。
小明1號發現參數類型傳錯，自己去修改了一下，沒來煩你，你甚至註釋都懶得寫，就開心的下班了。
方便閱讀、維護
類型系統實際上也是一個非常實用的文檔，大部分的函數通過查看類型的定義就可以知道如何使用，並且在vscode（此處使用vscode來代表所有代碼編輯器）裏面去編寫TypeScript時，vscode會根據你當前的上下文，把你能用的類、變量、方法和關鍵字都提示出來，一目瞭然。不僅如此，TypeScript的特性還增強了vscode的功能，包括代碼補全、接口提示和點擊跳轉等等
如下圖，我們可以很清晰的通過index.d.ts這個文件瞭解到cors這個函數的參數類型：
代碼提示：
那如果我不用TypeScript只使用d.ts不就好了麼？
當然也可以，只要你不嫌麻煩的話，因爲d.ts文件在TypeScript裏面一般都是用tsc自動生成的。
減少bug
在最上面的例子中，我們已經看到了vscode等IDE都會做出類型檢查，可以將很多類型錯誤直接提示出來，這一點在多人開發，和維護大型項目時尤爲重要，項目複雜，函數和變量繁多時經常出現一個人改了一點點東西，導致項目崩潰的情況，在TypeScript上面這種情況會大大減少。
但是值得注意的是，使用TypeScript也只能避免一部分錯誤，不能一勞永逸，平時遵守嚴格的編碼規範，配置eslint，代碼review，以及編寫單元測試等環節依然很重要！
社區活躍
繼Angular之後，React，Vue都相繼開始支持TypeScript，尤其是2019年更是TypeScript爆發性增長的一年，大部分第三方庫都開始有提供給TypeScript的類型定義文件。
學習成本
TypeScript因爲是在JavaScript的基礎上擴展，所以真正的學習成本並不大，但畢竟是靜態類型，而且需要理解接口、泛型、類、枚舉類型新的概念，對於習慣了JavaScript語言的人來說很難習慣，導致了很多前端工程師聽見TypeScript的第一反應都是拒絕，尤其是在看了用TypeScript編寫的項目後。
而且如果你想要在現有項目中充分體驗TypeScript，你又將面臨異常高昂的切換成本。
開發效率的降低
雖然類型系統自帶文檔，可以省去很多編寫註釋的時間，但是筆者親身經歷，爲所有值填上類型真的痛苦，筆者在參與同事編寫的h264播放器時，分分鐘想切腹自盡。
你以爲要寫的：
你實際要寫的：
人世間最痛苦的事情莫過於此，我5分鐘寫個方法，1小時才配齊文檔。
雖然TypeScript提供了Any類型，但是使用它的同時也失去了TypeScript的優勢，建議不要使用。
部分三方庫的兼容
隨着TypeScript的愈加火爆，很多依賴包都支持了TypeScript，但是依然有一部分還沒有支持，如果你的項目剛好依賴了它們而你還想使用TypeScript的話，那你就需要爲他添加一個d.ts文件纔可以使用，添加的過程有多麻煩，我只想說祝你好運。
需要編譯
JavaScript是標準，是可以直接在瀏覽器運行的，這一點對於需要編譯的TypeScript來說，是一個很大的優點。
我們對於TypeScript的使用
我們團隊目前使用TypeScript編寫的項目：1、h264播放器 2、錯誤日誌後臺
未來一段時間準備使用TypeScript編寫的項目：1、pc官網服務端重構 2、內部組件庫
綜合考慮
在開始播放器項目之前我們主要是基於以下幾點考慮：
對新技術的嘗試。組內人員對新技術的熱忱度都很高，希望通過一個項目來實踐TypeScript。
播放器是一對多類型的項目。使用播放器的人多且雜，難以保證都能按照文檔規範使用，我們希望過濾掉一些低級問題反饋。
多人協作。播放器項目龐大，且音視頻信息在各個函數中多是引用類型傳遞和修改，對於類型系統的需求大，每個人來編寫時都可以避免類型錯誤，並且方便獲取參數類型進行操作。
代碼規範化。開源項目，所以代碼越規範越好，TypeScript便於理解，並配有詳細的文檔。
新項目。從頭開發，沒有重構老代碼的成本。
項目地址：https://github.com/huajiaofrontend/HJPlayer
pc官網服務端重構我們主要是基於以下幾點考慮：
接口返回值固定類型。雖然有接口文檔，但是之前的接口交互時還是會經常出現php端需要進行類型強制轉換，或者js端進行類型強制轉換，很麻煩，用TypeScript可以很好的解決這個問題
持續維護。pc官網的服務端部分都是需要持續維護的代碼，使用TypeScript可以方便大家閱讀和後續擴展、重構。
不同系統之間類型獲取。開發人員不太可能清楚每個系統的數據結構，如果去閱讀又會浪費大量時間，TypeScript可以直接查詢到需要的數據結構並在編寫時代碼提示。
有很多人會問，TypeScript會不會像CoffeeScript一樣，在JavaScript引入標準後逐漸被拋棄，那我們還有學習的必要麼？
這一點筆者認爲，有很大可能是這樣的，但是我們沒辦法確定這個等待期有多長，即便是後續會被JavaScript引入標準，在這之前你就可以享受到上面我們所說的便利，這不香麼？
結論
是否使用TypeScript，筆者認爲在做出選擇之前，你需要認真的衡量一下投入產出比，TypeScript帶來的優勢是否對當前的項目有很大提升，是否值得花費大量的時間去對現有項目進行重構，值得注意的一點是，不管TypeScript最終會不會被應用到項目中，你都應該學會掌握它了，不要人云亦云。
最後，對於取捨問題，筆者的建議是：如果你的項目是大型項目，第三方庫，或者其他需要持續維護的項目，上TypeScript吧；如果你的項目是活動，分享頁面，等短週期並且不需要持續維護的項目，想用哪個用哪個，這裏我想說，動態類型的爽還是真的爽。
❤️ 看完三件事
如果你覺得這篇內容對你挺有啓發，我想邀請你幫我三個小忙：
點個「在看」，讓更多的人也能看到這篇內容（喜歡不點在看，都是耍流氓 -_-）
關注我的博客 https://github.com/SHERlocked93/blog，讓我們成爲長期關係
關注公衆號「前端下午茶」，持續爲你推送精選好文，也可以加我爲好友，隨時聊騷。
在看點這裏
