imho an intermediate bytecode makes no sense, as silentbicycle explained. 3 alternatives: 1) make every browser vendor implement multiple runtimes 2) x-to-js

imho an intermediate bytecode makes no sense, as silentbicycle explained. 3 alternatives: 1) make every browser vendor implement multiple runtimes 2) x-to-js translators 3) interpreters in implemented in javascript ad 1) multiple runtimes: not a good idea, because of multiple reasons. first, versioning hell. javascript is ~15 years old, and browser vendors are still not able to provide 100% compatibility. you'd have versioning hell, only worse. second, it would hurt javascript performance, because browser vendors would have to split ressources. third: which languages should be supported? you just couldn't please everyone, so there would be ongoing "why is language x supported but not y?" problems. ad 2) translators: are in use now. see coffeescript, gwt and ghcjs, ... pros: - almost native javascript speed - already possible cons: - small translation overhead (depending on if it's JITted or precompiled) - not everything is possible. if the javascript runtime doesn't support tail call optimization, the translation won't have it either. certain magic just doesn't translate. ad 3) interpreters implemented in js afaik there are some, e.g. js brainfuck interpreters. pros: - the sky's the limit - already possible cons: - slow (adds an emulation layer). that said, i'm against additional browser-provided runtimes except NACL. you could use javascript for your day to day work and NACL for your special needs. i'm not sure if NACL would be a complete stand-in for JS thought - would it be possible to communicate with the DOM (or at least JS)? if yes, there you have it - problem solved.