此篇文章適用于沒接觸過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吧；如果你的項目是活動，分享頁面，等短周期并且不需要持續維護的項目，想用哪個用哪個，這里我想說，動態類型的爽還是真的爽。
