Is there any reason the compiler should be written in Javascript? I know it's pretty cool to have a language's compiler written in itself, but what if Javascript isn't the best environment to write a compiler?
What's really nice about the compiler being in JavaScript is that you can run JavaScript anywhere: in the browser, on any OS, embedded in any major web framework. If the compiler were written in any other language, you'd have to worry about dependencies.
This applies to HTML and CSS preprocessors as well: I'd advocate Jade over Haml and Stylus or Less over Sass, simply because Jade and Stylus/Less aren't tied to the Ruby ecosystem. JS is the real deal for "Write Once, Run Anywhere."
Actually this is the opposite of my experience. It's actually "Run Anywhere, as long as you're on an Intel or ARM CPU".
I know I'm in a tiny minority of HN readers, but I have to deal with a pretty wide variety of UNIX platforms.. my code needs to run on SPARC, Itanium, etc. Sure most of these have a foot-and-a-half in the grave but one still is hanging in there: I still see a decent number of AIX customers; it'll be with me for the next few years at least. If something can't be made to run on a POWER CPU I can't touch it.
In the past, the widely used scripting languages (perl/lua/python/ruby/...) always treated CPU portability as sacrosanct. In time, there have been CPU-specific optimizations work done (LuaJIT, etc) but there is always a way to run the underlying language anywhere.
In the JS world, all of the modern work seems to carry an assumption that node.js is available, which in turn relies on the V8 JIT engine. V8 supports Intel, ARM, and (to some extent) MIPS CPUs -- IIRC node itself only supports the first two of those.
I'm all for optimizing for the 99%-case CPUs, but it's frustrating that I can't use these JS-based tools even at a large performance penalty.
I was heartened by the existence of the "SpiderNode" project since it would provide some engine diversity to the node.js world. From what I can tell it doesn't seem to be getting much traction in the wider community though, so I don't know if that's going anywhere.
Last I heard, the V8 team's opinion on portability was "ARM is our bytecode, just emulate that".. which is a fine answer as far as it goes. However, I haven't seen anything that actually implements this advice though (short of emulating an entire linux kernel in qemu) I keep hoping that V8 will add a fallback non-JIT mode for greater portability but I'm sure it's not a priority for Chrome.
So JavaScript portability has ended up in an unfortunate predicament: the language itself should be portable to "any OS" but in reality all of the non-browser projects have tied their wagon to a single engine.. and that engine doesn't have wide portability as a goal.
