> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input,

> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, relies extensively on engine quirks, and doesn't yet (ever?) address many hard problems like code caching and threading It's a spec for a subset of JS with guaranteed AOT compilation — it's hardly one that needs to go through a thousand committees to get somewhere where all those concerned are happy. If you want to do AOT compilation, everyone basically needs the same subset. Indeed, the most contentious part of asm.js is probably how you isolate it off from the rest of the script. It's simply not a spec that defines very much. And what engine quirks does it "extensively rely on"? If it relies upon anything apart from ES5, it's broken and the spec needs fixing. Similarly, it's out of scope for it to deal with anything like code caching and threading — the former is depending on how you tackle it either implementation detail (see how Carakan and V8 implement it today) or something really quite radical to the platform (but not something that needs to be immediately tackled), and the latter is one solution to a broader problem (parallelism in JS). Neither seem like things asm.js should be rushing to solve. An AOT compiled subset of JS is not in itself novel: this is not the first time it's ever been talked about, but what is novel (to my knowledge) is the idea of making compiler behaviour explicit for it, by having a token in code, along with isolating globals. Enabling AOT compilation is in many ways the "golden-grail", as although one must still be weary of compilation time (see SunSpider — many of the benchmarks complete in under 10ms, so you don't have the time to spend compiling them), the warmup time is currently relatively large.