Objective-J 直接在浏览器上编译/转换为 JavaScript。（这与在服务器上执行此操作形成对比，就像 GWT 对 Java 所做的那样。）除了 Objective-J 之外，是否已为任何语言实现了这种方法？
问问题
926 次
4 回答
14
CoffeeScript编译器将 CoffeeScript 编译成 ECMAScript 。由于 CoffeeScript 编译器本身是用 CoffeeScript 编写的，因此它可以将自己编译为 ECMAScript，从而在浏览器中运行。支持元素的必要零碎<script type='text/coffeescript'>已经包含在标准 CoffeeScript 编译器中。
一般来说，任何语言都可以编译成 ECMAScript，你只需要一个编译器。而且，由于任何语言都可以编译为 ECMAScript，因此任何编译器都可以编译为 ECMAScript，您所需要的只是编译器所用语言的编译器。
这导致在浏览器中编译语言的可能性组合爆炸。
例如，有一个人编写C 编译器，目的是为了好玩。他有一个编译器，可以将 C 编译成 Java、Perl、Common Lisp、Lua 或 ECMAScript。因此，您可以使用该编译器将任何其他用 C 编写的编译器编译为 ECMAScript。大多数语言在某处都有一些用 C 编写的编译器。
Clue 是用 C 编写的。Clue 将 C 编译为 ECMAScript。因此，您可以使用 Clue 将 Clue 编译为 ECMAScript。然后，您可以在浏览器中运行 Clue 以即时将 C 编译为 ECMAScript。<script type='text/c'>， 任何人？（有趣的想法：node.js 是用 C 编写的。嗯……）
更严肃的一点是：编译为 ECMAScript 通常有三个原因：
- 重用
- 安全
- 表现力
如果您只是想重用用不同语言编写的现有代码（或用不同语言编写的现有知识），那么在客户端上编译/解释没有多大意义。无论如何，代码或编码员都不希望能够使用<script>元素。此类别包括GWT或Volta 之类的东西。
如果（类型）安全是您的目标，那么在客户端上编译/解释根本行不通：如果您不控制编译器，如何保证安全？这就是为什么Ur/Web、Links、Flapjax、Haxe、Caja等在服务器上编译代码的原因。它们通过静态类型或紧密集成或两者兼而有之来保证安全性。（紧密集成是指后端、前端和应用程序紧密连接，例如指定一次数据结构，然后从该单一来源生成相应的 SQL、ECMAScript 和 HTML 表单，以确保它们都匹配。这应该是显而易见的为什么这需要在服务器上进行处理。）
然而，专注于表现力的那些希望被用作 ECMAScript 的替代品，即内部<script>元素，因此它们通常带有在客户端上运行的解释器和/或编译器。CoffeeScript、Objective-J和Clamato都属于这一类。
于 2010-10-09T02:18:06.293 回答
7
于 2011-01-07T13:01:14.933 回答
4
这是一个将类似 ruby 的语言编译为 javascript 的示例 - 编译可以在浏览器中完成。
于 2010-10-09T01:30:43.593 回答
0
于 2013-06-28T11:38:43.370 回答