Compile C to LLVM bytecode. Compile LLVM bytecode to Javascript.

Compile C to a subset of LLVM bytecode.

I fail to see how the second is harder than the first. In both cases, there are major implementation issues to overcome. The difference is that LLVM bytecode was designed to deal with this while asm.js is contorting an already problematic language and making unofficial (non-spec) guarantees.

The argument that compilers to JS exist is a non-issue because there already exist compilers from JS to LLVM (eg. javascriptCore). LLVM already has advanced optimizers that are well tested, so writing compilers targeting LLVM will already give a performance head start.

The argument that the bytecode is somewhat implementation specific does not matter for three reasons. The first is that a monopoly on implementation does not matter unless the choice was wrong (and even today, all the major JS engines share a lot of similarity in their high-level structure). Secondly, there are multiple LLVM JITs and native compilers around with each one having it's own take on implementation which seems to indicate that LLVM isn't that closely tied to a single way of doing things. Finally, in JavaScript itself, new features are not simply designed with the programmer in mind. A major factor is whether the big 4 find it easy to implement showing that JavaScript itself is implementation specific to those 4 companies opinion. Couldn't a bytecode do the same if necessary?

As there exists a way to compile LLVM code to JS code, backward compatibility with older browsers is simply a matter of adding an additional step in the compilation chain. The JS could check if LLVM was supported and browsers without support would simply ignore script tags that use LLVM.

As to the question of "why not just stick with JavaScript". I program in JS every day and really like most of the good parts of the language. This does not excuse the aweful parts of the language nor the problems it causes in real world companies where most programmers aren't "rock stars".

For a programmer new to JavaScript (even if they already have lots of programming experience), takes a disproportionately long time compared to other languages and until this is learned, the programmer is probably installing land mines that will need to be fixed later. Every fundamental feature of JavaScript (with the possible exception of closures) has a gotcha that you will run into (and not esoteric gotchas -- many of these will be run into very early on).

Even the most advanced of us find reasoning about JS inheritance to be nearly impossible for non-trivial systems and teaching this is even harder.

Aside from ubiquity, what reason is there to keep the language around? The only awesome features are that it's very function centric (minus proper tail calls) and it's combined dict/object take on prototypal inheritance is very nice to work with (unless you actually need to use the inheritance part).

LLVM bytecode was not designed to be a universal bytecode; it still contains architecture-specific information for code generation.

How long would it take for Mozilla, Google, Apple, and Microsoft to standardize on a common bytecode and then write compatible implementations for x86, ARM, and other platforms? NaCL or PNaCL are contender bytecodes, but Google is the only browser vendor that is interested.

JS is a standard language that already exists, so asm.js is backwards compatible with browsers that were shipped even before asm.js existed. The arguments for a universal bytecode over asm.js are mostly about elegance and "Better is Better." asm.js is definitely "Worse is Better" design.

http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...

One thing I want to comment on here is a mistake I often make myself, which is to focus on the language/compiler/interpreter/jit/translators/etc. and to loose sight of the platform APIs -- user interfaces, input devices, OS services, data sources, and so on. As fun as it is to talk about languages on HN, APIs are arguably a bigger part of the big picture in many platforms. LLVM itself doesn't come with any platform APIs, so it's typically just one part in a larger and much more complex system.

The LLVM lack of APIs is part of the appeal to me. It gives us a chance to remove the cruft on the APIs (because LLVM wouldn't be backward compatible anyway) and do them right or at least how we now believe they should be after screwing them up so many times.