The CoffeeScript compiler compiles CoffeeScript into ECMAScript. Since the CoffeeScript compiler itself is written in CoffeeScript, it can compile in ECMAScript and thus run in a browser. The necessary bits to support the <script type='text/coffeescript'> elements are already included in the standard CoffeeScript compiler.
In general, any language can be compiled in ECMAScript, all you need is a compiler. And since any language can be compiled in ECMAScript, any compiler can be compiled in ECMAScript, all you need is a compiler for the language in which the compiler is written.
This leads to a combinatorial explosion of possibilities for compiling languages in the browser.
For example, there is this guy who writes C compilers that target high-level languages for fun. It has a compiler that compiles C in Java, Perl, Common Lisp, Lua, or ECMAScript. Thus, you can use this compiler to compile any other compiler written in C in ECMAScript. And most languages have some kind of compiler somewhere written in C.
Summary written in C. Clue compiles C in ECMAScript. Ergo, you can use Clue to compile Clue in ECMAScript. You can then run Clue in a browser to compile C in ECMAScript on the fly. <script type='text/c'> , anyone? (Funny thinking: node.js is written in C. Hmm & hellip;)
In a more serious note: there are usually three reasons for compiling ECMAScript:
- Reuse
- security
- expressiveness
If you just want to reuse existing code written in another language (or existing knowlwedge in another language), compiling / interpreting on the client does not make much sense. The code or encoder does not expect to use <script> elements in any way. This category includes things like GWT or Volta .
If (type-) security is your goal, then compiling / interpreting on the client just doesn't work: how can you guarantee security if you don't control the compiler? Therefore, Ur / Web , Links , Flapjax , haXe , Caja and thus compile the code on the server. They guarantee security either by static text input, or with tight integration, or with both. (Due to tight integration, I mean that the backend, interface, and application are closely related to each other, for example, specifying data structures once, and then generating the appropriate SQL, ECMAScript, and HTML forms from this single source to make sure they all match. why does this require processing on the server.)
However, those that focus on expressiveness will be used as a replacement for ECMAScript, that is, within
<script> elements, and therefore they often come with interpreters and / or compilers that run on the client. CoffeeScript,
Objective-J, and
Clamato fall into this category.