本文转载自：众成翻译
译者：文蔺
链接：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 如许的转译器许可你设置对不稳固性的容忍度，不过你还须要应对更多的流失。别的，你能够采用越发深图远虑的设置，以下降不兼容的变化带来的风险，同时限定本身在更小的稳固的言语特征集合。”
