You seem to have your concepts mixed.

asm.js is a compiler that produces portable standard JavaScript output, like CoffeeScript or Elm or ClojureScript, except that its source language is C or C++. The output works on any browser supporting JavaScript, including Chrome and IE. It works very well on Chrome and Mozilla (haven't tried IE recently - old IEs would be slow due to missing TypedArrays and friends, but it would still work).

Yes, the created JavaScript is annotated in a way that Mozilla uses to improve speed (and other browsers can, though they do not yet as far as I know) - but those annotations are still perfectly standard JavaScript that even the oldest IE is not confused by.

The main use that I'm familiar with for asm.js is to make use of an existing C/C++ codebase. See e.g. all of https://github.com/kripken/emscripten/wiki/Porting-Examples-... and especially the utilities section. Rewriting Poppler, GnuPlot, eSpeak or SQLite in JavaScript is no small undertaking - and asm.js makes this rewrite unneeded.

> Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem.

While using the asm.js toolchain may not be trivial (or it may be - I last tried it a long, long time ago), it is only the outputs that are meaningful for end users, and those outputs are already compatible with every other browser. The assertion about a Mozilla only ecosystem makes absolutely no sense.

> and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.

Those who ignore history are doomed to repeat it. This idea has been aired in some way or another since the early 60s. And yet, every single implementation has failed to deliver on the goals of a "one true VM" (yes, including the CLR, JVM, UCSD p-Code, and tens of other that did gain some traction). The best "true VM" we have today is, surprisingly, x86 and AMD64 bytecode. It has a hardware implementation, which makes it wicked fast compared to all the others - and it is also significantly lower level than any "true VM" proposed to date.

Luckily, Mozilla is learning from history and not ignoring it.

> I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them.

...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to anything else, except NaCl I suppose (though that requires more porting effort).

I don't get what you mean by "going through the trouble of compiling their application to asm.js" versus ""normal" javascript wasn't good enough for them.". Why would they compile to normal JS? There's no reason to: Their codebase is in C, C++, or some other native code language. If they compile to asm.js, they get a free performance boost. If they compile to JS, they just get horrible slowness. The only difference between them, here, is a single compiler flag. I don't understand.

> Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');?

Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?

> Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem.

What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js.

> I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.

It's not a VM, there's no JIT involved.

If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up).

> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?

Normal JS developers would use asm.js if they needed extra performance. I occasionally need extra performance out of javascript, so I use heavily optimized clojurescript, which helps for some applications. If I had exhausted those options, I would try programming in C and compiling to asm.js.

> What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js.

Ha. You obviously haven't tried to do that yet. asm.js is intended to be a compiler target for many languages. It only succeeds for two languages (C/C++), thanks to emscriptem more than asm.js, and even that is not trivial. It takes significant effort to port most C/C++ applications...otherwise they wouldn't have their own codebases, they would just be a different target on a makefile. If it were as simple as you make it out to be, we would have hundreds of languages compiling to asm.js by now; C/C++, but also every language that compiles to C/C++ or LLVM bytecode. As it is, we have maybe a couple dozen large legacy codebases that have been ported.

> It's not a VM, there's no JIT involved.

A VM does not necessarily imply JIT, but that is beside the point. A VM executes bytecode, and asm.js is an attempt to use javascript as bytecode. Javascript wasn't designed as a VM, and several of its "features" actively subvert its use as a VM, which is why asm.js relies on guarantees that you will not use those features.

If getting the performance that asm.js developers expect out of asm.js requires the use of a browser that optimizes for asm.js, then the solution isn't cross-platform. In fact, it isn't really any better than NaCL, god forbid.

> If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up).

I'm not sure that's really true. It doesn't have to be ultra-fast, just good enough.

> If it were as simple as you make it out to be, we would have hundreds of languages compiling to asm.js by now; C/C++, but also every language that compiles to C/C++ or LLVM bytecode. As it is, we have maybe a couple dozen large legacy codebases that have been ported.

Er, well, there aren't many languages which compile to native code. People can't compile Java, C#, JavaScript, Perl, Python, Ruby, PHP, etc. to native code. C/C++ do compile to native code, however.

> Ha. You obviously haven't tried to do that yet.

Oh, I have. I realise it has some difficulty to it.

> If getting the performance that asm.js developers expect out of asm.js requires the use of a browser that optimizes for asm.js, then the solution isn't cross-platform. In fact, it isn't really any better than NaCL, god forbid.

I'm not sure what you think asm.js is the solution to. Its purpose is for running native applications in the browser. It's not for making ordinary JS apps run fast.

> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?

asm.js is a compiler target, true. Is it really that much C specific? Isn't it possible to compile parts of JavaScript to asm.js? For example the parts which deal with drawing - computing points of - complex things on a canvas? That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's not available, I can imagine some people doing this by hand. Remember that people used to code in real asm all the time a few centuries ago.

> asm.js is a compiler target, true. Is it really that much C specific?

No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java.

> Isn't it possible to compile parts of JavaScript to asm.js?

Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however.

More seriously, no, not really. JS is a dynamic language. It can't be compiled ahead-of-time.

> For example the parts which deal with drawing - computing points of - complex things on a canvas?

No, you couldn't compile that to native code. If you tried, I doubt it'd be faster than your browser's existing JIT.

> That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's not available, I can imagine some people doing this by hand. Remember that people used to code in real asm all the time a few centuries ago.

You could hand-write asm.js, but it'd be difficult. Manually manipulating the heap and stack isn't fun. There's no memory allocator included. It would make far more sense to just write in C, compile it, and write glue code, or just to write easily JIT-ed JS in the first place.

> Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however.

Tell this to Google Closure Compiler folks :)

> More seriously, no, not really. JS is a dynamic language. It can't be compiled ahead-of-time.

I don't think that's true. For a counter-example consider Dylan: it's AOT compiled to binary, yet it's rather dynamic. There are many AOT compiled Scheme implementations, and Scheme is rather dynamic, too. I think you can AOT compile everything, it's just a matter of how huge a runtime you'll need to provide. There's probably a point where it's more trouble than it's worth, but in principle you should be able to compile anything. Asm itself is very dynamic language, with dynamic code generation, code rewriting or dynamic evaluation all over the place, so I really don't think there's anything preventing you from doing so. Besides how impractical that would be, of course :)

But I wasn't actually thinking of JS as a whole, but of some specific, computation-related subset of it.

For example, let's assume that I'm writing a function and I promise to only use integers in certain range and arrays with elements of same type and with fixed, immutable length. I promise never to divide by 0, and never trigger overflow, and never access an array out of bonds. It seems very restricted, but actually that's rather common in some domains. Knowing these restrictions I'd probably be able to compile my function to asm.js and have it AOT compiled, bypassing JIT, avoiding some overhead and - most importantly - knowing exactly what optimizations were used (because it was optimized by my "crippled.js" -> "asm.js" compiler).

I think I saw this idea being implemented in a couple of languages, but I don't remember exactly when it was.

Oh, and I have nothing against manual memory manipulation. I rather enjoyed working with asm on some platforms and I'm very fond of Forth. But that's me, I don't expect others to like it too.

> No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java.

asm.js is directly relatable to something like C, yes. But languages like C# are possible as well, if you add another step. For example, Unity compile C# into C++, then C++ into asm.js.

This would be even harder for arbitrary JS, of course, as it's much more dynamic than C#. Still, it would be an interesting experiment.

I'm not sure you really can compile C# directly to native code. A subset, maybe, but not C# proper.

Yes, I think it's a subset, some of the more dynamic things are probably not supported.