看完Peter's article on JavaScript我注意到了
Brendan Eich stated that one the goals for Harmony is to be a better target for to-JavaScript compilers.
目前有两个流行的编译器有一些模糊ES:Harmony合规性:
虽然 CoffeeScript 有一些合规性，但它并不是为 ES:Harmony 编译器而设计的，因此它对此没有用处。
Tracuer 似乎更加严格地遵守 ES:Harmony 规范，但我不知道它是否打算成为一个完整的 ES:Harmony 编译器。
由于目标是将 ES6 编译为 ES3，因此它还需要支持 ES5 功能(并且可能需要切换是将 ES5 编译为 ES3 还是将 ES6 编译为 ES3)。
- 目前是否有任何其他项目旨在创建完整的 ES:Harmony 到 ES3 编译器？
- 在知道标准还很年轻/不稳定/不断变化的情况下开始编写这样的编译器是否明智。
- 目前是否有任何 ES5 -> ES3 编译器？
我在 Traceur mailing list 上留下了问题.
这种编译器的目标是向后兼容 ES3。 ES3 中没有完全模拟 ES5 和 ES6。
最佳答案
(下面无耻但相关的插件)
Caja正在通过 ES5/3 修改其 ES5 支持并将为 ES 和谐做同样的事情。因此，我们的结构将被实现为一个 Harmony 到 ES3 层，对于真正的 Harmony 实现可以跳过它，然后是一个可分离的加载器，它保留与 caja 相关的安全属性。
与 Traceur 一样，Caja 团队的成员也是 TC39(定义 ES Harmony 的委员会)的成员。
我不知道 Coffeescript 的计划，但在讨论 Harmony 模块时提到过它。 Module loaders可能有能力拦截加载的源代码(通过 eval hooks )并在模块初始化之前重写它，因此如果模块是用 CoffeeScript 编写的，则可以在初始化时调用运行时 CoffeeScript 重写器。这将允许应用程序由以多种语言编写的模块组成，这些模块在加载时编译为 Harmony。
需要注意的是，并非 Harmony 中的所有内容都可以通过翻译轻松实现。例如，实现 weak maps正确地需要在 JavaScript 中实现您自己的垃圾收集器，即使您这样做了，您也可能只会重新引入宿主对象/ native 对象循环问题。
关于javascript - ECMA脚本 :Harmony/ES6 to JavaScript compiler，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6506519/