有了Babel的話還在使用TypeScript的優勢在哪？

---

我覺得題目本身的定位就有一些問題。。

這裡暫且分成兩個方面考慮：

• TypeScript 相比 ES6/7 有什麼優勢；
• tsc 相比 babel 有什麼優勢。

1. TypeScript 相比 ES6/7 有什麼優勢

ES6/7 並非是一無是處的，比如 ES Module 就是一個很好的設計，其靜態特性保證了實體的唯一性，也確實能夠為靜態分析提供很大的幫助。（比如已經可以基本保證重構時的引用完備性，不會誤傷不會遺漏）另外也提供了大量的語法糖為開發者提供便利。

只是，對於大型工程而言，這樣可能還不夠。

TypeScript 的定位是靜態類型語言，而非類型檢查器。

從 Tooling 上來說能提供的優勢也遠不止類型檢查，比如很直接的一點就是 Intellisense over Compilation Error，一段代碼，當你寫了前兩個字母沒有提示了，或者寫完就有個紅波浪了，那它就已經錯了，而不是等到編譯的時候再告訴你第幾行有錯。（可能很多人在大學學 C 語言的時候已經有斯德歌爾摩綜合&症&征了？）

而作為開發人員唯一要做的，就只是在介面處標明類型，其它的內部過程交由 ts 推理就好。

而如果不進行標註，只靠自頂向底的類型檢查的話，那麼當出現類型不相符的時候，就會出現和運行時一樣的錯誤棧，又如何知道到底是哪一步到哪一步寫錯了呢？

極端一點的方面，如果是在 FP，組合變換了十幾二十次，然後還腫么能明確每一步拿到的都是什麼呢？如果有 ts 的話，只要你提供了初始的標註，那麼後面每一步的過程也都是明確的了，哪怕返回到中間改了一個什麼東西也能立刻知道對後面有沒有影響。

2. tsc 相比 babel 有什麼優勢

這點很難說，因為二者的定位並不相同。

Babel 是一個 JavaScript 預處理器的基礎設施，雖然本身為 es6 而生，但現在 es6 對 babel 而言也只是一個普通的 preset 而已。

理論上完全可以基於 babel 實現一個 ts 的編譯器，但上面就已經談到了，ts 的核心並不在那一個編譯器。如果我們從 npm 上下一個 typescript 的發布版本，可以看到，在 lib 中，除了 tsc 之外，還有一個很重要的 tsserver。ts 本身也貫徹語言即服務的理念（參考 C# 的 Roslyn），所有編輯器、IDE 都能很方便地利用，避免重複造輪子。

總的來說，tsc 的功能沒有 babel 多，擴展性也沒有 babel 強。但對於 tsc 所覆蓋的那一部分（也就是 ts），tsc 做得比 babel 更好更精。而 ts，很多時候也就恰恰是 JavaScript 工程實踐中所最需要的那部分。

---

隨便說一點

公司現在的前端項目大概有十幾萬行代碼，各種從後端拿到的數據類型有上百種

以前後端介面一改，要改欄位，瞬間懵逼。

全局搜索，一個個改，各種牽扯到的東西改下來再測試一頓估計小半天沒了。

用了 TypeScript 之後，把數據對應的 interface 改掉，然後重新編譯一次，把編譯失敗的地方全部改掉就好了。

而且在優秀的 TypeScript 架構中，業務開發基本不需要寫類型，所有外部輸入的類型都可以自動拿到，只需要把一些 local variable 和 output 的類型定義一下就好了，基本跟手寫 ES 6 沒有區別。

寫代碼的過程中各種錯誤在越早期修改的成本就越低。試想沒有靜態檢查跑一遍代碼進某個奇怪的 case 才能復現的錯誤在寫代碼時期就直接給你的個錯誤提示，將是多麼省時省力省錢。

---

更新：刪掉以前的評論，看著有點搞笑。

當前的見解：babel面向輸入輸出、管道化、碎片化、組織工具、微創新、微挖坑、解決已知問題…typescript面向開發過程、面向設計，引入傳統的開發模式，結合當下敏捷開發體驗，自成體系，或者佔據體系中重要的位置（tsd，vscode，angular，tsx……），與babel有輕度互斥，亦敵亦友。

利益相關：10年js從業，4.5年ts開發。

---

前面答主說得很好了：TypeScript。

坦白說 ES6 對我沒什麼吸引力。很多語法只是帶來混亂，像 generator 這樣的特性我也並不喜歡。 而像原生 Promise 這樣的特性也很容易可以找到簡單的 polyfill。

而 TypeScript 對我很有吸引力。尤其是寫 Scala 一類的有不錯的類型系統的語言寫多了以後，沒有強類型整個人都不太好。TypeScript 提供的面向對象特性也強於 ES6。

---

為什麼需要類型系統

---

說真的，前端的同學們應該去寫一些強類型語言的代碼，體驗一下強類型的好處，對比一下弱類型的不足，將會有一個比較清醒的認識。

es6更多的是從語法層面來改進js，就我而言我覺得是沒有必要的，這麼大一個版本，折騰了那麼多年才定下來，就加了語法糖，而且語法糖還是個半吊子（class，解構）有啥意思？

我個人覺得開發大一點的應用最關心的應該是兩個問題：模塊管理與類型檢查。

模塊管理用於多人合作，類型檢測用於避免低級錯誤。

typescript目前來說應該是做得比較好的之一了（flow沒用過），interface，class，泛型，類型，結構該有的都有。編譯階段可以檢測出許多低級錯誤，省去一堆isxxx函數、參數判斷、返回值判斷、結構屬性有效判斷。亂傳參、亂調方法的低級錯誤編譯都通不過。

真的會省很多不必要的時間。

一些前端開發人員認識不到interface的作用，也比較不容易理解泛型、結構這樣的概念，所以抵觸typescript，這樣真的不好。

個人意見，可以不學babel，es6的語法可用可不用（我不太明白有些前端團隊為什麼不強推ts，反而強推es6）。但是typescript可以搞一搞。Java、C++之類的可以搞一搞，就當玩了。

---

發現力挺ts的基本上是後端。

其實就是角度不同，

目前，寫js代碼的有兩種人，一種是前端，一種是後端。

在沒有做前後端分離的時候，js代碼涉及到數據的時候，往往是後端的人寫的，後端的人思想轉變不過來，就喜歡強類型。為了達到目的，後端想出了兩種方法，一種發明就是typescript，CoffeeScript這樣的，類js，另外一種就是clojurescript一類的,直接轉成js的。好壞不說，存在即合理，確實解決了不少人的問題。

ok，現在再說，前端。本人知識有限，只接觸過python,es,php等動態語言與java，c++，C#等編譯語言。總的來說，各有各的好處。但是對我們前端而言，es（es3/5/6/2016）是標準，只要瀏覽器一天不放棄js，那es就是必須掌握的。現如今es6/7功能很強大，配合node，babel，我們現在也一樣用上了es6、7.而且現在有前後端分離技術，從此，寫js的權利將收歸前端所有，後端不用在管js了。我們的地盤我們做主，堅決使用es6、7即可。

最後在來分析一下typescript的用戶群體。主要就是vs的忠實用戶與angular團隊。背後代表的就是微軟與谷歌。這兩件公司一家主打c#，恨不得什麼都是c#。一家主打java，恨不得什麼都是java。包括angular本身都是基於java的思想。現在谷歌發現完全基於java思想的angular不太適合前端了，所以他才要推出angular2。

所以，我的建議就是，es是標準，我們前端人員就向標準靠攏。至於ts，angular一類的東西，有時間，有精力，有需要，那就去學，說實話，在掌握es6的基礎上，學ts也就1天學會。但是我們前端要牢記，es就好比是我們的內功心法，是一切的根本，其它的什麼jq，angular，react，typescript，node，babel等等，都是工具，隨時可以被替換的

---

js對於大型項目，保證讓你體會到什麼叫「開發一時爽，重構火葬場」，除非測試覆蓋的很好，不然真沒法一堆水平有差異的人愉快的玩耍。

---

Nativus es.

你要是用過 ts 的類型機制保證不會有這種論斷。當然你要是經常寫奇葩代碼的話另說。

ps. ts 的後端興許可以拿出來作為 transpiler 的公共後端也說不定，不過貌似他的 AST 不是正交的……

---

TypeScript 無論從功能、眼界和未來都比 Babel 好。TypeScript 是一種編程語言，有一整套的周邊設施以及及強大靠山。Babel 只能和 CoffeeScript 做對比

但是未來是什麼樣的真的不好說。 像 Anders 在去年在國內 TypeScript 演講中的那句話一樣：Microsoft Change

---

語言一定要先學強類型的

---

同意_@Trotyl Yu的回答。這裡我再補充幾點。

傳統JS開發往往依賴設計模式和文檔，才能保持代碼的高可維護性。這點在ts層面，就可以事半功倍了。

首先，ts對編輯器的友好類似於intellij對java的友好，比如代碼提示，參數檢查等等，其次介面代碼的引入，可以讓開發者不必擔心參數錯誤，將更多精力放在邏輯層面。

es6在語法上確實與ts非常接近。但正如ts的名字所述，type checking才是ts的核心賣點。tsc和babel是它們各自的module compiler，雖然最後編譯出的都是es5，但要說這兩家誰更優秀或者誰能替代誰，這個都依賴於具體的場景。

比如在處理語法sugar時，es6擴充了語法，隨著版本的升級，具備更多的靈活性。

而ts的嚴格性對AST語法樹及code reference更友好，更加可規範化。目前據我所知，ts可能會成為webassembly規範的備選語言，這也是個利好。

總之，es6配合babel、ts配合tsc這兩者在不同的場景下各有優劣。

---

一個改動，一編譯，哦原來還有這些地方也要改一下

---

Babel 和 TypeScript 根本不是一類東西。看到這問題也是醉了。

---

沒啥好比的，ts寫完基本就能跑通js你試試。。

---

因為可以避免這種低級的運行時問題。

---

babel preset es6再加flowtype才能和typescript比吧，就像前面說的，babel和typescript真的不是一個東西

---

babel的哲學其實和一般的編譯器一樣. 但是讓人總覺得有點奇怪.

傳統的編譯器,逐級降階. 即 代碼(人) =&> AST中間碼(人與機器之間) =&> 平台二進位碼(機器)

只不過在babel中 最後的 "平台相關代碼" 變成了 js. 可問題在於 總覺得 AST(抽象語法樹) 比 最後生成的js 更低級. 但這種更低級的結構卻不能被執行,反而要再次轉換成比較高級的腳本來被執行.. 你說蛋疼不蛋疼. 權當是為未來 webassembly 做些鋪墊吧.

這樣做最大的好處 也許是可以比較隨意的添加一些語法糖,以及給語言本身打一些補丁(十日做出javascript,確實漏洞一堆)...

再說 ts 和 babel 的一些區別.

ts可以說是專門為大型工程而設計的, 它借鑒了C# 很多優秀的思想,比如泛型 介面類 等等,這些都不是 es6 標準里的,但是對於大型工程來說又是非常有用.....

babel 通過很多插件可以自定義編譯方式, 如果你想為 你的js源碼加一種新語法, 那麼只要你實現對應的 plugin 就可以. 靈活度 高於 ts.

---

題目應該問反了吧，？？

而且巨行(業務類型)js項目沒編譯器檢查，怎麼玩。

---

Type啊，另外工具鏈的選擇不是完全由優點決定的，個人習慣也很重要……

---

一個是真實的東西，另一個是套了一層的玩意

---

lz，babel是有問題的，ts專業得多。

我就遇到過babel的坑，沒辦法只好換成ts。

以前有點猶豫，是因為ts要typings這些玩意兒，現在沒辦法，只好上ts了。

babel的代碼編出來，你可以與ts編出來的對一下。

ts編出來的代碼明顯規範得多。

更別說編譯器內部的一些坑，babel要爬出來還得很長的路。

---

推薦閱讀：