【译】关于转译器 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 这样的转译器容许你设置对不稳定性的容忍度，不过你还须要应对更多的流失。另外，你能够采起更加深思熟虑的设置，以下降不兼容的变化带来的风险，同时限制本身在更小的稳定的语言特性集中。”