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.
