拋棄 JS，使用 TypeScript
最近幾個月我已經全面拋棄 JavaScript，完全使用 TypeScript 進行前端開發（只在上課的時候用到 JS）。
先說優點：
- bug 顯著減少，之前會遇到的 xxx 為空的問題幾乎不會出現了，類型相關 bug 直線減少。
- 應用更可控，當你需要約束某些代碼的時候，用類型就能很簡單地做到，比如 React 裏強制寫 displayName 方便調試。
- 查文檔更方便，以前要打開瀏覽器看文檔，現在直接查看定義就基本明白了。
再說缺點：
沒有。哈哈。
現在只會 JS 的前端要怎麼辦？
不用慌，TS 的代碼跟 JS 差不多，你學完 JS 後，只需要學習一下類型聲明就可以掌握 TS 了。
如果你公司的項目目前只支持 JS，也沒有關係，只需要加一個 ts-loader 或者 awesome-typescript-loader 就能提供 TypeScript 支持，TS 可以和 JS 共存哦。
然後你就可以逐步用 TS 代替 JS，實現完美過渡。
為什麼 TypeScript 是好的？
如果你現在還沒有開始學習 TS，肯定是因為對 TS 有所顧慮。去問問用了 TS 的前端感覺怎麼樣吧，基本沒有一個說後悔的。所以這種顧慮是完全沒有必要的。
那麼 TS 為什麼這麼好呢？接下來我們從理論上解釋一下。
- 寫代碼最怕什麼？代碼出錯，也就是 bug。
- 如何避免 bug？運行代碼看結果，或者添加各種測試。
- 現在前端並不流行單元測試，所以只能運行代碼看結果（比如刷新頁面，然後用滑鼠點點點，看是否能運行成功）
- 但當你的前端應用非常大的時候，你不可能每次改代碼之後去所有頁面上點一遍，因為頁面太多了。
- 所以前端選擇模塊化，讓一次代碼改動影響的頁面盡量少。但是即使這樣，你依然無法通過滑鼠點擊測試來運行所有代碼，因為你可能還需要測試多種不同的賬戶。
- 這樣做太麻煩了。有沒有什麼辦法能讓我快速知道「代碼有bug沒」
這是一個重要的問題：有沒有什麼辦法能讓我快速知道「代碼有bug沒」。
為了說明類型是如何解決這個問題的，我們先來介紹一種最簡單的類型：正負數。
我們把實數分為三種類型：正數、負數和0。
然後看下面這個等式：
28937829 * -1239282 = 35862130598778
聰明的你一眼就看出這個等式不對。為什麼？因為「正數」乘以「負數」必然得到「負數」。所以我們根本不用運行這個乘法，就知道這個結果不對。
這就是類型的好處。
類型能讓你「大概」知道代碼對不對
TS 就是在 JS 上加上類型聲明，這樣我們就能知道代碼是否「大概」正確。
另外，這種方式速度非常快，快到你只要修改代碼，TS 就能告訴你代碼是否「大概」正確。
從而避免很多 bug。
你只需要稍微花一點點時間，就能讓代碼質量提升，何樂不為呢？
聽說 TS 只適合大型項目？
錯，只要是有 bug 的 JS 項目，都可以用 TS 替代 JS 從而減少 bug。
所以無論是小項目還是大項目，都有必要使用 TS。
萬一過幾年 TS 不火了呢？
這個問題問得好，前端發展這麼快，很多東西都是火幾年就不火了，導致後期想招人維護都難（比如 AngularJS 1）。
但是 TS 不存在這個問題。為什麼？
因為目前前端三大框架全都支持 TS 了：
- Angular 很早就支持 TypeScript 了，而且還把 JS 從自己的名字裏去掉了：AngluarJS -> Angular。甚至連 Angular 入門文檔裏的例子都默認是 TS 版本的。用 JS 寫 Angular 不是不可以，只是會顯得很「奇怪」，明明有更好的 TS，為什麼會有人用 JS。
- Vue 3.0 用 TS 重寫了，為了更好的支持 TS，甚至放棄了原本計劃推出的 class API。
- React 一開始對 TS 的支持也是非常絲滑。不過 React 並沒有強綁定到 TS。
如果有一年 TS 不火了，上面框架的維護者會提前為你想好升級方案的，你就不必過多擔心了。
畢竟背靠大樹好乘涼。
JS 豈不是白學了？
No No No，TS 裡麪包含了 JS 的所有語法，所以你在用 TS 的時候，實際上還是在用 JS。
也就是說 JS 的魂還在，我們只是不再單獨使用 JS 了。
結論
快點學 TypeScript 吧，它很快就是一線互聯網公司面試加分項甚至必備項了。
反駁
如果你有什麼需要反駁的，歡迎反駁，但是請給出充足的理由，無意義的站隊和灌水評論會被我刪掉，這樣我們的討論才會更有意義。
沒有看完文章就評論的，也會被刪除。
推薦閱讀：
