【发布时间】：2019-03-10 22:04:19
【问题描述】：
Objective-J 直接在浏览器上编译/转换为 JavaScript。 （这与在服务器上执行此操作形成对比，就像 GWT 对 Java 所做的那样。）除了 Objective-J 之外，是否已为任何语言实现了这种方法？
【问题讨论】：
标签： javascript compiler-construction objective-j
【发布时间】：2019-03-10 22:04:19
【问题描述】：
CoffeeScript 编译器将 CoffeeScript 编译成 ECMAScript。由于 CoffeeScript 编译器本身是用 CoffeeScript 编写的，因此它可以将自己编译为 ECMAScript，从而在浏览器中运行。支持<script type='text/coffeescript'> 元素的必要零碎已包含在标准CoffeeScript 编译器中。
一般来说，任何语言都可以编译成ECMAScript，你只需要一个编译器。而且，由于任何语言都可以编译成ECMAScript，任何编译器都可以编译成ECMAScript，你只需要一个那个语言的编译器编译器是写在里面的。
这导致在浏览器中编译语言的可能性组合爆炸式增长。
例如，有一个人为了好玩而写C compilers which target high-level languages。他有一个编译器，可以将 C 编译成 Java、Perl、Common Lisp、Lua 或 ECMAScript。因此，您可以使用 that 编译器将任何用 C 编写的 other 编译器编译为 ECMAScript。而且大多数语言在某处都有一些用 C 编写的编译器。
Clue 是用 C 编写的。Clue 将 C 编译为 ECMAScript。因此，您可以使用 Clue 将 Clue 编译为 ECMAScript。然后，您可以在浏览器中运行 Clue 以即时将 C 编译为 ECMAScript。 <script type='text/c'>，有人吗？ （有趣的想法：node.js 是用 C 编写的。嗯……）
更严肃的一点：编译到 ECMAScript 的原因通常有三个：
- 重用
- safety
- 表现力
如果您只是想重用用不同语言编写的现有代码（或用不同语言编写的现有知识），那么在客户端上编译/解释没有多大意义。无论如何，代码或编码员都不希望能够使用<script> 元素。此类别包括 GWT 或 Volta 之类的内容。
如果（类型）安全是您的目标，那么在客户端上编译/解释根本行不通：如果您不控制编译器，如何保证安全？这就是为什么Ur/Web、Links、Flapjax、Haxe、Caja 等在服务器上编译代码的原因。它们通过静态类型或紧密集成或两者兼而有之来保证安全性。 （紧密集成是指后端、前端和应用程序紧密连接，例如指定数据结构once，然后从该单一来源生成相应的 SQL、ECMAScript 和 HTML 表单，以确保它们都匹配。应该很明显为什么这需要在服务器上进行处理。）
然而，那些专注于表现力的，希望被用作 ECMAScript 的替代品，即在 <script> 元素中，因此它们通常带有在客户端上运行的解释器和/或编译器。 CoffeeScript、Objective-J 和 Clamato 属于这一类。
【讨论】：
-
哇，那真是……有趣。弹出两个泰诺。
-
非常酷的答案！我得试试 CoffeeScript。
这是一个将类似 ruby 的语言编译为 javascript 的示例 - 编译可以在浏览器中完成。
【讨论】：
【讨论】：