【譯】關於轉譯器 JavaScript 程序員須要知道的

本文轉載自：衆成翻譯
譯者：文藺
連接：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 編程模型能夠愉快地共存，它們甚至還能健康地競爭、相互借鑑。」

擴展 JavaScript

與此相似，他評論 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 個的擴展插件；「人們爲特定的庫、工具（如代碼檢測）、瀏覽器優以及代碼壓縮等編寫插件。」

Standards at Scale

此外，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 這樣的轉譯器容許你設置對不穩定性的容忍度，不過你還須要應對更多的流失。另外，你能夠採起更加深思熟慮的設置，以下降不兼容的變化帶來的風險，同時限制本身在更小的穩定的語言特性集中。」