asm.js - The Good, The Bad or The Ugly?

Lots of things happening this week in JavaScript realm. The most amazing and at the same time contradictory is asm.js that was merged in the latest Firefox Nightly. asm.js is a subset of JavaScript that is optimized as good as half-native performance.

Mozilla loves colorful demos, but the one from this video has blown the JavaScript community. To show the power of their new tech Mozilla folks ported Unreal Engine (more than a million lines of code) to asm.js and launched a demo inside a browser.

So what is asm.js and where does the speed comes from? Technically it is a subset of JavaScript, but in reality it is a different language: static and much stricter. It is designed to be JavaScript-compatible and thus can run by browsers, but it is not JavaScript. Have a look at the code:

// Based on the example from 2ality.com
function TestModule(stdlib) {
  "use asm";

  function foo(x, y) {
    var x = x|0;
    var y = +y;
    return +(x * y);
  }

  return { foo: foo };
}

Those |0′s are the types of variables hidden within the regular JS syntax. You can’t have something like:

var x:int = 0; // the way of ActionScript

because language doesn’t permit it. But still you need to provide some type info – so this is the solution. asm.js is not meant to be a language for reading or writing. asm.js is a target for compilers like emscripten that translate from higher-level languages like Java or C++ to JavaScript. The real-world asm.js code generated by emscripten looks like in the image below.

asm.js code sample

asm.js takes out all the sweet parts of JavaScript: dynamic nature and closures, removes all operations except for arithmetic, adds strict typing and a very unforgiving verifier. What it gives in return is compilation and optimization Ahead of Time (AOT) instead of Just in Time (JIT). The result is crazy speed, Unreal Engine running in Firefox Nightly and a cryptic language that looks more like bytecode.

It is too early to measure pros and cons of asm.js; some very smart people like Vyacheslav Egorov are really concerned about this trend. What I see is the new opportunity, which opens up new possibilities and creates new problems that we will have to address.

  • I am very excited that it is possible to port millions of C/C++ code to JavaScript and run it in browser with the almost-native performance (could you release the source of Heroes of Might and Magic 3 please, I want it in Nightly)
  • asm.js code is a neither readable nor writable code. It is most likely hell to debug, meaning that your asm.js project is always tightly coupled with the source code on a high-level language. On the other hand it is not a problem for Dart and CoffeeScript
  • I’m concerned that “use asm” would provoke vendors to do their own “use IEasm”, “use OperAsm”, “use whateverelse”. We might be standing right in front of next “vendor-specific” stagnation period of endless shims, hacks and fallbacks

[UPDATE] More news coming from the fronts. In this interview EPIC Games reveals some plans towards making Unreal Engine 4 Web-compatible. What’s the big deal you ask? Think about the amounts of textures and data that you would need to transfer over the wire before playing. It will most likely stimulate more advanced offline-storage APIs and capabilities. Snowball Effect?

If you want to read more on the subject, here are few great links: asm.js homepage http://asmjs.org/ with links to spec and a nice presentation that gives more details about the motivation and mechanics of this extension.