在網上搜了一圈前端使用ts的優缺點，各種拿去跟ES6,JS比較的。你說你跟eslint校驗比較下tslint還有理可循，你跟JS,ES6是在比啥呢？
本篇文章總結一下使用TS的優"缺"點。

先說好的

1.個人在使用TS的時候，基本上把介面檔案抄了一遍，介面一旦有任何的輸出不對勁你都可以很明確的知道到底是誰在瞎幾把改欄位，熟練掌握後慢慢的你可以自己定義介面交給伺服端，這樣可以少點轉接器，當然使用了ts還用個p的轉接器
2.如果你的程式碼足夠規範的話，一旦增刪改了公共介面，提交資料的函式或者跟這部分資料有關的頁面和函式立馬全部報錯，你只要對著主控臺一個個修復增刪改的欄位就行了，當然dom部分的程式碼還是得手動修復。這點非常有利於別人維護你的程式碼。以前改程式碼的時候我總是戰戰兢兢，改了一個介面生怕哪裡疏忽了沒改，畢竟不是你自己寫的，就算是自己寫的時間久了也容易忘記，現在好傢夥，只要一改介面相關頁面全報錯了，我tm直接好傢夥。

個人認為第二點真的尤其好用，用了TS你再也不用對老專案唯唯諾諾了，現在只需要修改相應的介面檔案，你就可以對老專案里的程式碼重拳出擊了。

說完好的，再來說說缺點

1.TS最大的缺點就是費程式碼，費鍵盤！以至於很多小夥伴在剛開始用TS的時候認為這個東西毫無用處，我之前在使用了相當長一段時間的TS後都是這麼認為的，直到我體驗到了上述兩個優點，所以這東西真的是見效太慢了！十分之勸退新人。
2.除此之外，TS還有一些美中不足的地方，例如不能與時俱進，檢測不到資料雙向繫結的dom里的欄位是否正確，這個功能急需主流三大框架幫咱們彩筆程式設計師解決一下，要是能把dom模板一併檢測了，那真的是美滋滋。
3.我個人認為TS最大的問題就是沒有try catch這樣的拋錯與例外處理方法，如果能在檢測到錯誤的時候丟擲一個可以被捕獲的異常的話，那真真是極好的，有時候我們就是需要資料是錯誤的，例如number型別的資料給了一個非number，我們就可以透過一些方式提示使用者資料應該為數值，而不是資料存在非number的可能性就必須將資料定義為number|非number,當然這點是個人理解。