摘要：他們的計劃是，使用微軟開發者們所習慣的其他語言的開發工具所支持的靜態類型，得到更好的代碼。在微軟內部，被和以及團隊所使用，而且它被系的等公司使用。標準的編輯，同時也是微軟項目高級經理的也同意。

本文轉載自：眾成翻譯
譯者：文藺
鏈接：http://www.zcfy.cc/article/895
原文：http://thenewstack.io/javascript-transpilers-need-know/

想要在與 ECMAScript 保持一致的同時也不拋棄那些沒有最新 JavaScript 特性的瀏覽器嗎？或者在成為標磚之前試驗那些即將到來的特性，以告訴 ECMAScript 哪些對你有用，哪些沒什么用？再或者就是想利用那些大型項目中提高 JavaScript 效率的工具？轉譯器（transpiler）可以幫你完成所有這些。

轉譯器是將一種語言的代碼轉換為另一種語言代碼的工具，它們過去曾被更多地用來轉換替代性語言如 CoffeeScript、ClojureScript、Elm，甚至還使用像 C 和 C++、Emscripten（將 LLVM 二進制碼轉換為 asm.js 代碼） 這樣的語言。Mozilla 的政策與研究主任 Dave Herman 指出，這并不是要替代 JavaScript，“多種 Web 編程模型可以愉快地共存，它們甚至還能健康地競爭、相互借鑒。”

與此類似，他評論 TypeScript、PureScript、Flow 以及 JSX 這樣一些給 JavaScript 增加自定義擴展的轉譯器“對 Web 來說是偉大的”。

TypeScript 是 JavaScript 的超集，支持可選的靜態類型，還有一些工具，它們提高代碼編寫效率，支持重構，還可以偵測錯誤，從方法名的書寫錯誤到因類型錯誤而無法執行的操作都能被檢測到。你可以試驗帶有類型安全特性但同時保持可讀性的 JavaScript，而不用深陷在其他語言如 Dart 或 CoffeeScript 之中。

當初，使用 TypeScript 來編寫 Babylon.js 的時候，David Catuhe 指出來，“使用 Babylon.js 的開發者不會察覺到 TypeScript 編寫的新版本與 JavaScript 編寫的老版本之間的差異。”他還提到，引入 TypeScript 幫助他找到了許多之前在代碼中一直存在的小 bug。

使用轉譯器，意味著開發者在編碼的時候可以使用更新的特性和 API，總的說來，這同時也會幫助社區發展。 —— Henry Zhu

對那些大量編碼大團隊來說，這些好處能帶來巨大的效率提升。這正是 2011 年 TypeScript 啟動時，微軟所尋求的。Office Online 網頁應用擁有超過 100 萬行的代碼，“那時候做這樣的 app，可沒那么多可以使用的工具”，TypeScript 前任項目經理 Jonathan Turner 告訴我們。他們的計劃是，使用微軟開發者們所習慣的其他語言的開發工具所支持的靜態類型，得到更好的 JavaScript 代碼。

VS Code 和 Visual Studio 很好地支持 TypeScript，也有 Sublime、Emacs 和 Vim 的 TypeScript 插件，還有其他一大堆工具正在支持。TypeScript 被許多項目選中，比如說，Angular，Asana，Dojo，Mozilla 的 Flash 替代產品，以及 Babylon.js WebGL 框架、JavaScript 遠程調試工具 vorlon.js。

在微軟內部，TypeScript 被 Bing、 Visual Studio 和 Visual Studio Online、Azure 以及 Xbox 團隊所使用，而且它被 Adobe、Google、Palantir、Progress（NativeScript）、eBay 系的 SitePen 等公司使用。

除了擴展 JavaScript，TypeScript 還可以將代碼轉譯為匹配多種 ECMAScript 標準的代碼，這讓你可以出更少的力氣支持多種瀏覽器，還能提前使用 ECMAScript 標準的建議。

這個特點也被開源的 Babel transpiler 所支持，這是另一個 JavaScript 轉譯器。

“轉譯器允許開發者編寫面向未來的代碼，哪怕當前版本的語言不被任何環境支持，” Babel 核心團隊的 Henry Zhu 解釋道。“比方說，如果你要支持不含任何 ES2015 特性的 IE 瀏覽器，那就必須要轉譯了，因為 IE 對新語法一無所知。Babel 就是中間的一層，讓你無需考慮正在使用什么瀏覽器、指定哪些需要轉譯的特性。瀏覽器實現規范需要時間，他們在增量進行。如果沒有自動更新特性，可能用戶永遠不會更新 JavaScript 版本，所以唯一的辦法就是編寫新版本的 JavaScript 然后再轉譯。”

和 TypeScript 一樣，Babel 不僅僅是轉譯，Zhu 提到。“Babel 是 JavaScript 轉換通用性工具。它并不只是將 ES6 轉到 ES5。” Babel 擁有超過 1000 個的擴展插件；“人們為特定的庫、工具（如代碼檢測）、瀏覽器優以及代碼壓縮等編寫插件。”

此外，Zhu 說，“使用轉譯器，意味著開發者在編碼的時候可以使用更新的特性和 API，總的說來，這同時也會幫助社區發展。”

“規范的創造者們在 TC-39 處理的 stage-0 到 stage-4 過程中（譯者注：原文 “TC-39 stage process from stage-0 to stage-4”，可以流程可以參考譯文《ES7新特性及ECMAScript標準的制定流程》）可以接收到提案的反饋，如果有人為其編寫了插件，” Zhu 說道。“因為有廣泛的用戶基礎，Babel 允許許多用戶嘗試實驗特性，相對于只是被沒有‘真實世界’測試的語言作者所認可，這有助于塑造更好的特性。許多提議都在 Github 上，任何人都可以給未來的提案提供建議，只要它還在往前發展。”

Herman 對他所謂的 “標準轉譯技術的采用，特別是 Babel 的成功” 充滿熱情。“對開發者來說，最現實的誘惑就是利用 JavaScript 的改進之處，哪怕引擎（瀏覽器或 Node.js）尚未提供原生支持。不過因為這些特性是基于標準的，開發者們可以放心大膽地使用，而不必擔心大的兼容性變化。在快速進化的 JavaScript 生態系統中，這對開發者的價值，怎么說都不為過。”

ECMAScript 標準的編輯，同時也是微軟 Edge 項目高級經理的 Brian Terlson 也同意。“轉譯器十分重要。JavaScript 程序員通常都想使用最新特性。迎合最小公分母是很悲催的，沒人想做這事。轉譯器讓我們得以直接使用新語法，這你所鐘愛的、提高你效率的、讓你的應用更具維護性的語法 —— 然后將其編譯為可以在那些老頑固的瀏覽器上跑起來的東西，你希望市場上再也不要有這些老頑固了，可不幸的是它們還在。轉譯器在 JavaScript 社區如何書寫代碼這方面起到了變革性的作用。”

開發人員早期的使用和反饋，帶來了良性循環，Herman 說。“轉譯器已經引發了新特性的超前使用與社區實驗的浪潮。這讓開發者們有能力在真實的生產環境中的應用里面使用新特性，并且對更新到最新版本特性的頻度和時間有了控制。這也就意味著更多的開發者正在參與標準特性的早期審查，使他們在變化化的過程中有了更強的聲音，最終帶來更好的標準。”

“多虧有了轉譯器，未來版本的特性正在持續獲得大量的早期試用。（比如）裝飾器（Decorators）讓類定義中抽象通用模式（pattern）成為可能，它在 Web 框架如 Angular、Ember 及 React 中大受歡迎，” Herman 說道。Ember.js 社區很早就采用了 Babel，Herman 說這讓許關于模塊系統（module system）的多可用性反饋進入到 ES 2015 中。

開發者的反饋也推動了裝飾器的標準化，Terlson 說。“早期在轉譯器中實現的特性真的是很大的、引人注目的特性，像裝飾器就是這樣；這對那些特性設計的迭代非常有幫助。”

“如果你所知道的某個特性真的能改善你的代碼和你所工作的應用，” 他建議，“趕緊在轉譯器中做起來或使用 polyfill，用起來，然后給我們反饋。”

轉譯器是解決新特性無法進入 ES 標準除非其已被實現的雞生蛋還是蛋生雞的問題的一種辦法。不過瀏覽器廠商們不太愿意實現尚未標準化的特性，因為這可能導致開發者們無法與特性的標準保持一致，這些特性在標準化的過程中會有所變化。

ES 2015 不需要之前的實現；“結果就是，” Terlson 解釋道，“在我們批準某些特性如 Proxy 之后，實現者們遇到了標準中沒有體現的東西，所以在現實面前，我們不得不做修改。這體現出在批準那些標準之前確保特性將按照標準實現有多重要。”類似問題還有尾調用優化，這并非巧合，Zhu 提到了那些無法在轉譯器中嘗試的特性。

在新版本語言出爐之前，語言的維護者需要程序員們提供反饋。Terlson 認為，轉譯器就是其中重要的一部分。“轉譯器幫助我們得到語法上的反饋。擁有 Babel 和 TypeScript 這些轉譯器，我們真的很幸運，這讓我們在瀏覽器實現之前就能使用試驗新語法。對某些特性來說，我們相當自信，如果有轉譯器 或 polyfill 外加瀏覽器，它們將會工作。”

轉譯器能比瀏覽器更快地開發新特性， Herman 指出，“Babel 由 JavaScript 實現，而瀏覽器們是用 C++ 實現的，所以功能更容易做出來。一些特性要同整個瀏覽器整合起來，可能是更棘手的挑戰。JavaScript 引擎都有復雜的、多層 JIT 編譯的構架，這常常意味著僅僅一個特性需要多次實現，每層實現一次。而且相比實現新的 JavaScript 特性，瀏覽器引擎開發團隊的責任更多，所以他們要衡量優先級。”

轉譯器不可能給你提供所有新特性，Herman 指出，“某些特性，如 ES 2015 的 Proxy，或者當前的 SharedArrayBuffer 提議，基本上不可能通過轉譯器來實現。其他的，像 ES 2015 的 Symbol，可以部分實現，不過有一些已知的局限。這一類的問題，需要開發者們多注意，他們必須確保不會依賴那些轉譯器無法正確實現的行為。”

隨著 ECMAScript 標準的發展，轉譯器也不會將你同 JavaScript 的變化隔離開來。“需要提出一點警告，” Terson 提到，“我們會聽取使用轉譯器特性的開發者的反饋，有可能標準會因此變更。針對標準，在其完成之前，我們可能做出重大改變，所以當你使用超前于標準的特性時，我們會提出警告。”

即便如此，它們能幫助你過渡，Herman 說。“當升級轉譯器新版本的時機到來，讓其因實驗語言特性不兼容的改變而打破你的代碼，這會很麻煩而且耗時不少。因此，像 Babel 這樣的轉譯器允許你設置對不穩定性的容忍度，不過你還需要應對更多的流失。另外，你可以采取更加深思熟慮的設置，以降低不兼容的變化帶來的風險，同時限制自己在更小的穩定的語言特性集中。”