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.
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.