如果 ES2015 完全普及了，我們還需要 Babel 嗎？

需要。因為 Babel 幫助開發者提前嘗試使用尚未正式成為規範的 ES 特性，以便評估新特性的價值。

ES 規範現在是每年更新，ES 2015 普及了，後面還有 2016、2017、2018、……。TC39 的 ES 規範推進流程會把新特性提案分為五個階段，其中 Stage-2 要求新特性有兩個 demo 實現，其中一個就可以是包括 Babel 在內的轉譯器。只要有包括 Babel 在內的工具成功實（模）現（擬）了新特性，就可以視為滿足 Stage-2 的要求。在後面的階段要繼續推進，就再等待瀏覽器等運行環境進行實驗性的原生支持。

不一定需要 Babel 這一款特定的工具，但需要一款有這種語法解析、語法樹操作和重新輸出的工具。Babel 其實不是第一款，在它之前就有 Esprima，但當時大家都不知道操作語法樹能做什麼，覺得這只是少數人玩的工具。Babel 第一次讓大家看到，這種工具可以用來把一種高級 JavaScript 語法轉譯為另一種 JavaScript 語法，而且 ES6 轉譯提供了顯而易見的便利。將來 JavaScript 的擴展必然會依賴於這項技術。

Flow 對 JavaScript 的轉譯使用的也是類似的工具，儘管工具是用 OCamel 寫的但能轉譯為 JavaScript 然後被其它 JavaScript 調用。這是 JavaScript 強類型化的一個方向，如果沒有這樣的工具就沒辦法做了。為什麼要做強類型呢？這樣很多錯誤可以通過靜態分析捕獲，不需要等到運行時才被發現出來。結合伺服器端代碼的強類型化，可以保證伺服器端和客戶端交換的 JSON 一定是類似的，不會有一個屬性伺服器端當作整形來讀寫但客戶端當作字元串來讀寫。

大規模的代碼重構和遷移也可以用這類的工具來做，例如 jscodeshift 就是一個例子。如果代碼要從 React 一個版本遷移到另一個版本，某些 API 的使用要跟著遷移，你敢用正則表達式替換嗎？正則表達式是可能出錯的，因為它並不能用於解析 JavaScript，這時候 jscodeshift 就能派上用場了。你匹配和替換的不是字元串而是語法子樹，這就保證了操作的安全性。

再舉個例子，現在在 JavaScript 中有個變數名為 fn，它指向一個函數，你能夠告訴我這個函數實在哪個源文件第幾行定義的嗎？我可以在 JavaScript 轉譯時悄悄對這個函數進行一個包裝，在包裝上加上標註屬性，讓你能夠知道這個函數是在哪裡定義的。我甚至還能悄悄在包裝上對函數進行打點記錄，然後告訴你這個函數被調用了多少次以及每次調用的耗時。

在 ES3 早已普及的現在，我們需要 Babel 嗎？

當然需要，因為項目越來越複雜， ES3 已經不能滿足我們了。

同理，在 ES2015 完全普及的未來，ES2015 也早就不能滿足我們了(其實現在已經滿足不了了)。。。所以 Babel 還是必要的。

但是，如果項目簡單，能避免使用高級語法和特性，那就不需要 Babel。

ES 2015 只是一個版本的特性，後續還會有更多的規範更新， Babel 的作用不在於將 ES 2015 轉化為現今瀏覽器能夠執行的代碼，而在於將最新的、實驗性質的、待評估的特性轉碼實現並運行於現有的瀏覽器上

當然，因為還有es7，es8等等

Babel是提供新特性語法轉換成現代瀏覽器可識別運行語法的工具，ES2015是某一個時期的標準。

假設ES2014時期題主問了一個問題，如果ES2014完全普及了，我們還需要babel嗎？

然後過了一年，ES2014其實已經完全被瀏覽器識別了，來到了ES2015時期，那你覺得現在需要babel嗎？答案肯定是需要的～哈哈，當然我們不一定非babel不可，我們需要的是支持驗證新特性的轉譯工具。

Babel 已經是一種規範落地工具了。

另外 ES2015 普及這個說法太強硬了，不是某個有關部門在強推規範，而是社區按照流程，先把規範提出，再逐步討論最終落地，而提案是否能通過，取決於討論，而討論很多依據來自實踐效果，實踐效果很多來自 babel 對新特性的提前支持。

需要 因為 babel 還有 ES2016+

但是如果是一些快速項目 就不需要了

畢竟編譯出來的代碼 比較難修改