[1] about 3/4 into this interview: http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-MachineCoffeeScript is far from perfect--it has syntax quirks of its own--but it's more pleasant for me to write in, being used to Python and Ruby. (And, yes, I understand JavaScript too; I just don't like the syntax.)
Eventually transcompiler languages will evolve to take advantage of different JS engine improvements. So far, this isn't a goal of CoffeeScript, but other abstraction layers might already be doing that.
I wonder what opportunities there are here that haven't been exploited yet and that don't require replacing JS with a new language. For example, could JS implementors define a more-easily-optimizable subset of JS? Then transpilers seeking performance could target just that subset.
Transcompilers that were target-specific could probably target server-side JS at first. e.g. If you're just building a node.js app, there's no reason for the polyfill language to make any concessions to IE, for example. So one "optimization" is simply avoiding legacy cruft in the generated output. But I could also see exploiting specific features of cutting-edge JS engines.
Transcompilers that were target-specific could probably target server-side JS
I had an idea recently that (to me at least) is super exciting: someone should make a good language that compiles (à la Coffeescript/Parenscript) to JS but also to Lua. JS and Lua are close semantically, so it might not be so hard. (If it did turn out hard, it probably wouldn't be worth doing.) That would be a really interesting server-side alternative to both Dart (whose philosophy appears to be "run our VM on the server and compile to JS for the client") and Node.js.
Mentioned in http://www.aminutewithbrendan.com/pages/20101122.
JS is becoming the compiler target "bytecode", without needing verifiers or new and complex standards to be adopted by multiple browser vendors.
JS has gaps as a target language, for sure. We are working on filling them (e.g. 64-bit and other int types).
These are easy bugs to fix compared to creating a new, portable, and future-friendly bytecode standard in addition to keeping up with a competitive JS engine. Since JS is incumbent, it's hard for any browser vendor to justify a new thing with zero users at first, and too much risk of non-standardization or JVML-like albatross status.
Can we reconsider using this thing as the assembler for the web? Can we come up with a sane, cross-platform bytecode standard?