除了 Objective-J 之外还有其他语言可以“编译”吗？浏览器中的 JavaScript？

发布于 2024-09-27 05:29:19 字数 118 浏览 4 评论 0原文

Objective-J 直接在浏览器上编译/转换为 JavaScript。（这与在服务器上执行此操作形成对比，就像 GWT 对 Java 所做的那样。）除了 Objective-J 之外，这种方法是否已针对任何语言实现？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

逐鹿 2024-10-04 05:29:19

CoffeeScript 编译器将 CoffeeScript 编译为 ECMAScript。由于CoffeeScript编译器本身是用CoffeeScript编写的，因此它可以将自身编译为ECMAScript，从而在浏览器中运行。标准 CoffeeScript 编译器中已包含支持

一般来说，任何语言都可以编译为 ECMAScript，您所需要的只是一个编译器。而且，由于任何语言都可以编译为 ECMAScript，任何编译器都可以编译为 ECMAScript，因此您所需要的只是该语言的编译器编译器被写入。

这导致在浏览器中编译语言的可能性组合爆炸。

例如，有一个人为了好玩而编写针对高级语言的 C 编译器。他有一个编译器，可以将 C 编译为 Java、Perl、Common Lisp、Lua 或 ECMAScript。因此，您可以使用that编译器将任何其他用 C 编写的编译器编译为 ECMAScript。大多数语言都有一些用 C 编写的编译器。Clue

是用 C 编写的。Clue 将 C 编译为 ECMAScript。因此，您可以使用 Clue 将 Clue 编译为 ECMAScript。然后，您可以在浏览器中运行 Clue 将 C 即时编译为 ECMAScript。

更严肃地说：编译为 ECMAScript 通常有三个原因：

重用
安全
表现力

如果您只是想重用用不同语言编写的现有代码（或用不同语言编写的现有知识），那么在客户端上编译/解释没有多大意义。代码或编码器无论如何都不希望能够使用

如果（类型）安全是您的目标，那么在客户端上进行编译/解释根本不起作用：如果您不控制编译器，如何保证安全？这就是为什么 Ur/Web、链接，Flapjax，Haxe、Caja 和这样在服务器上编译代码。它们通过静态类型或紧密集成或两者来保证安全。（通过紧密集成，我的意思是后端、前端和应用程序紧密连接，例如指定数据结构一次，然后从该单一源生成相应的 SQL、ECMAScript 和 HTML 表单，以确保它们全部匹配。这应该是显而易见的，为什么这需要在服务器上处理。）

然而，那些专注于表达性的人希望用作 ECMAScript 的替代品，即在

The CoffeeScript compiler compiles CoffeeScript into ECMAScript. Since the CoffeeScript compiler is itself written in CoffeeScript, it can compile itself to ECMAScript and thus run in the browser. The necessary bits and pieces to support <script type='text/coffeescript'> elements are already included in the standard CoffeeScript compiler.

In general, any language can be compiled to ECMAScript, all you need is a compiler. And, since any language can be compiled to ECMAScript, any compiler can be compiled to ECMAScript, all you need is a compiler for the language that compiler is written in.

This leads to a combinatorial explosion of possibilities for compiling languages within the browser.

For example, there is this guy who writes C compilers which target high-level languages for fun. He has a compiler that compiles C to Java, Perl, Common Lisp, Lua or ECMAScript. So, you can use that compiler to compile any other compiler written in C to ECMAScript. And most languages have some compiler somewhere which is written in C.

Clue is written in C. Clue compiles C to ECMAScript. Ergo, you can use Clue to compile Clue to ECMAScript. Then, you can run Clue in the browser to compile C to ECMAScript on the fly. <script type='text/c'>, anyone? (Fun thought: node.js is written in C. Hmm …)

On a more serious note: there are generally three reasons for compiling to ECMAScript:

reuse
safety
expressivity

If you simply want to reuse existing code written in a different language (or existing knowlwedge in a different language), then compiling/interpreting on the client doesn't make much sense. The code or the coder doesn't expect to be able to use <script> elements anyway. This category includes stuff like GWT or Volta.

If (type-)safety is your goal, then compiling/interpreting on the client simply doesn't work: how can you guarantee safety if you don't control the compiler? That's why Ur/Web, Links, Flapjax, Haxe, Caja and such compile the code on the server. They guarantee safety either by static typing or tight integration or both. (By tight integration I mean that backend, frontend and app are tightly connected, by e.g. specifying data structures once and then generating the corresponding SQL, ECMAScript and HTML forms from that single source to make sure that they all match up. It should be obvious why this requires processing on the server.)

The ones that focus on expressivity, however, expect to be used as a replacement for ECMAScript, i.e. inside <script> elements, and thus they often come with interpreters and/or compilers which run on the client. CoffeeScript, Objective-J and Clamato fall in this category.

回复收藏 0 原文