I'm starting to hear rumblings about this project called ASM.js. Currently their web site is terrible and confusing. Here's what I know from my research on the web.

  • It is a subset of JavaScript that can be highly optimized. I'm guessing because it avoids the more dynamic parts of the language.
  • Performance of code compiled to ASM.js runs at about half the speed of C (not light).
  • The intention is for compilers to make their target language ASM.js.
  • Firefox is going to be shipping with ASM.js optimization baked in.
  • The Mozilla and Unreal teams ported the Unreal Engine to the web with it and its running in a build of Firefox at near-native speeds.

There doesn't seem to be any concrete information on the web about what this really is or the usefulness or ultimate purpose. Is it that I can compile my otherwise server-side code bases and have it run in the browser at close-to-native speeds? What are the ramifications for developers?


2 Answers 2


You already described what it is. The use is that it's a low-level language that works across all browsers, is quite fast in most and very fast in some. What you make of this is as open-ended as what you do with any other programming language.

The use case Mozilla seems most keen on is this: There are already ways of compiling languages with LLVM backends (most prominently C and C++) to JavaScript, via Emscripten. asm.js is very close to what Emscripten already emits, so this allows Emscripten code (which is already impressively fast on today's JavaScript JIT compilers) to become even faster, furthering the goal of porting existing code bases to the web. Again, what exactly you use this for is your decision. Porting games is one use cases (which Mozilla is apparently actively involved in), but there are countless things written in C and C++, quite a few of which might come in handy for someone's web site. Some I've seen flung around (plus some of my own devising), with no guarantee regarding feasibility:

  • Porting general-purpose algorithms (e.g. zlib, libjpeg, openssl, FFT implementations) to empower JavaScript/websites to do more, without having to create a new web standard and depending on individual browsers to implement it.
  • Porting interpreters, so that languages other than JavaScript can run in the browser, with less overhead and minimal porting effort.
  • Using asm.js as a backend for more compilers, especially those that don't map well to JavaScript and don't need most of its features and overhead. An example could be a language designed for fast numeric work with no memory allocation.
  • Using asm.js to create a JIT in JavaScript. It may implement any language at all -- for example ActionScript.
  • In the same vein, porting existing JIT compilers to run in the browser (cf. porting interpreters, with effectively nil overhead over JS). This is probably only feasible when JIT compilers are automatically generated, as with PyPy.
  • 2
    Here is another good explanation: ejohn.org/blog/asmjs-javascript-compile-target Commented Apr 3, 2013 at 18:36
  • 1
    Here's a proof of concept for porting a JIT to asm.js. It's a unique selling point, most emerging platforms aren't JIT-friendly.
    – Tobu
    Commented Jan 26, 2014 at 22:54
  • Is there an explanation somewhere of how asm.js supports JIT compilation? Can't seem to find any info on that. Most interested in how the security implications are handled. Commented Sep 6, 2014 at 13:35
  • @romkyns JIT compilation of asm.js to machine code by browsers, or JIT compilation to asm.js (by a JavaScript program)? For the former, at least in Firefox, the machine code generation facilities of the pure-JS JIT compilers are re-used. Since asm.js can only call into JS, perform arithmetic, and read/write a heap array with index-in-range checks the security is about as good as the security of JS execution. For the latter, you just generate asm.js source code and let the browser execute it, and there are no additional security implications beyond what I mentioned before.
    – user7043
    Commented Sep 6, 2014 at 14:02
  • (I meant the latter) Ooh of course; somehow I imagined JIT compilers emitting native machine code. Thanks for the clarification! Commented Sep 6, 2014 at 17:10

Imagine ASM.js as a big binary ArrayBuffer called a heap and a set of JavaScript modules, which begin with a prologue directive: "use asm"; and perform fast low-level operations on raw binary data, similar to assembly languages. Those modules could be written by hand or better compiled from LLVM code by scripts like Emscripten. Their performance could be boosted thanks to the Mozilla OdinMonkey engine, but they are backward-compatible with most of the modern ECMAScript interpreters.

ASM.js is not limited to games, you can even run whole Qt apps in your browser, like these!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.