NaCL is not portable and PNaCL will never be a standard, because it's very complex, very implementation specific and the other browser vendors will never adopt it. Quite the contrary, I view PNaCL as being the hack you're talking about, being Google's version of ActiveX.

The great thing about JavaScript is that it can be used as a compilation target, like bytecode. There are already many compilers that do that, like ClojureScript and Scala.js, I'm working on a mixed JVM/JS project in Scala right now. And I get the secure sandbox, the portability of JS and the tools for free. Which is the advantage of a standard, otherwise I might as well go native.

And given that you can compile C++ to JavaScript with really good results, I really don't get what problems you're trying to solve. And yes Mozilla is responsible for making this happen, getting everybody on board with ASM.js, even Microsoft. And I find that to be a great development.

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.

JavaScript is open and free.

Also, with Rust, they are already developing another language.

You might be right with the monoculture problem, but JS is a big thing with many developers, it would be dumb not to use this resource.

Do you think it's also worrying that we all communicate in English? Is the English language a stagnated monoculture?

Pandering to language fanboys isn't a good idea. Javascript is a good enough language, and if you don't like it, write in something else and compile it to javascript.

I'm not smart or experienced enough to know the answer to this, it's an honest question. Doesn't compiling things to javascript inherently limit what we can do? For example, if a feature is supported in some other language but not javascript then I imagine even if there were a way to compile to javascript, there might be a severe performance impact.

I guess what I am saying is that it seems like we are stuck with javascript for historical reasons and it's a shame that we aren't exploring other options. Of course, I can also completely see that sticking with javascript is the most practical option as well.

> Doesn't compiling things to javascript inherently limit what we can do?

Yes, any concrete compilation target has limitations, including JavaScript.

For example, in JavaScript, there are no 64-bit integers, which can slow down some code. As another example, strings on .NET and Python are different, causing Python on the CLR to either behave differently or run more slowly.

I think the important thing to realize is that there isn't a "perfect" compilation target. What we really want is a target that is (1) fast on all languages, (2) portable to run on all OSes and architectures, and (3) safe to run in a sandboxed manner. There is no target I am aware of that maximizes all 3. All we can do is try to get close.

I would say that JavaScript is doing pretty well in that respect already (that is, like all other options, it isn't perfect, but it's relatively decent), and remaining missing features are being worked on.

> it's a shame that we aren't exploring other options.

I don't think that's true at all - such experiments have been done! We had or have ActiveX, Java, Flash with its multiple VMs, Silverlight/.NET, NaCl, PNaCl, and others I forgot.

Given the performance of JavaScript engines today, those experiments of other VMs don't show a big enough reason to prefer them. asm.js code runs fast enough to run AAA game engines, which is a very good test.

Thanks for the response. I'm glad to see that I was wrong. asm.js looks extremely promising

Think of JavaScript as the JVM, CLR or ABC of the Web runtime. Now imagine someone trying to add a sperate bytecode/intermediate language to those runtimes. There are security issues and architecture issues to consider.

The language monoculture problem exists just as much on other runtimes as it's does on the Web. It's just nobody is expected to write in JVM or CLR.

That's why projects like asm.js and Emscripten are important. These projects show vendors what things are needed to make JavaScript into a better compile target so that someday writing in other language for the Web is as natural as it is on JVM and CLR.