(1) Depends on how different the source language is from the semantics of JS. JS is a high-level language and doesn't have e.g. goto which would make it easy to

(1) Depends on how different the source language is from the semantics of JS. JS is a high-level language and doesn't have e.g. goto which would make it easy to implement different execution models. If you don't want to create your own interpreter in JS (which would be an alternative to code generation), you have to be manage with functions (and exceptions). If the source language require more powerful constructs like goto or continuations, you are out of luck. (Theoretically you could gain some power by compiling to a continuation-passing style, but since JS engines doesnt have TCO, I dont think this would work in reality. The scoping rules combined with the distinction between expressions and statements means that it is harder to generate composable snippets. For example you cannot just generate a small "context free" code snippet with a local variable - the scope of a variable is always the function, so you need either to mangle the name to create a unique variable, or create an inline function and call it - but that changes the semantics of return, which again is a hindrance to composability. I would definitely prefer something like scheme as a compilation target, but it could be a lot worse. Imagine compiling to VBScript :-) For my particular project which compiles ES5/Harmony to JavaScript it works quite well, but those languages are based on JavaScript anyway, so that is almost cheating. (2) AFAIK the working group are a aware of the interest in JS a compilation target, but are not at the time considering adding features specifically to make it more suitable for that purpose.