1樓：aemoe
因為每增加乙個編譯器都是一次build時間增加而且typescript還不和js一樣 Js可以向下相容會ES6的ES7的寫這些不會的繼續ES4，ES5 所以不會有太大問題而且用的這些新的功能是早晚會被瀏覽器支援的所以用起來很放心所以除非TypeScript受到瀏覽器的支援之前我都不建議在乙個不可控的團隊中使用TypeScript 如果你的團隊可控性非常強喜歡新技術那沒任何問題用吧
2樓：太狼
已經很易用了，react.d.ts 甚至已經支援了很新的 default generics，React 周邊的很多倉庫也有對應的 .
d.ts 了，可見用 ts 寫 React 的人還是挺多的。
3樓：藍形參
Typescript 2.0之後，tsd和typings都可以去掉了。要獲得lodash的型別定義檔案只需要npm install @types/lodash
這樣一來，typescript的工作流就和普通的Node.js專案沒什麼區別了。
更重要的是Typescript 2.1之後，async/await可以直接編譯到ES5。babel什麼的，再見吧
4樓：niexw
個人看法：
1）前端開發正在走向大型化，專業化。以往前端附屬於後端的現象，估計很快就會改變。基於這樣的認識，前端開發的語言就是乙個大問題。
2）js從誕生之初，就缺乏完整的設計，這麼些年來不斷的修修補補，離開發大型專案的要求仍然很遠。
所以說，機會就在眼前，但是es6/es7都不會獲得這樣的機會了。機遇不會等待es的完善，就讓js變成前端的彙編吧。
5樓：Trotyl Yu
稍微更新下兩個重點。
1. TypeScript 1.8 開始支援了 AllowJS 選項
所以現在可以直接引用 js 檔案而不需要對應的 .d.ts 檔案也不會報錯（當然，也就沒有那麼良好的型別提示支援）。
2. DefinitelyTyped （tsd）已死
現在 TypeScript 的 .d.ts 管理已經全面轉向 Typings（GitHub - typings/typings:
The TypeScript Definition Manager），後者具有更好的版本控制、平台管理、Registry 管理支援（其實與其說 Typings 多好，不如說 tsd 完全是翔）。
所以，個人目前遇到的最大問題是，缺少某些 Type Definition 檔案。這個問題目前基本可以視為已解決。
6樓：
我覺得 TypeScript 1.5 以後, 國外很多大公司還在用 JS (ES6+Babel) 寫些重要的開源庫這種行為真是令人費解. 還整什麼 Flow.
js. 真是閒的蛋抽筋.
還有那些以 JS 以編譯目標的語言, 居然不出 *.d.ts -> host-lang 的生成工具, 大把 Type Definition 資源不用, 瞎折騰.
TypeScript中的never型別具體有什麼用？
崮生 export async function proxy api fun par P Promise par P,Promise data 這個方法要求api一定返回data 也就是 T data 但實際上有些介面他喵的沒有data這個時候我一般定義data為never型別，我覺得這個場景應該算...
TypeScript 使用的型別系統，相比傳統靜態語言有哪些優缺點？
張振衣 ST 比較解耦吧，只需要描述結構，拿著值就可以寫型別了，這一點在 ts 之於 js 是非常必要的。不然真的閉關乙個季度改型別，我需求別做了。還有另乙個角度，叫做如何看待同構 isomorphic 和相等 equal ST就認為同構只不過是名字不同，實際計算時相等的。而NT就認為名字不同的型別...
typescript寫後端的優勢是什麼？
Jason5Lee 我最看中 TypeScript 的是型別系統的表達能力。TypeScript 支援 Discriminated Union 又稱代數資料型別 空檢查 諸如 T undefined 一類的 record 即全部都是屬性的介面，能通過物件字面量建立，從而達到類似某些語言 struct...