Why asm.js?

Developing a JavaScript application in C/C++ may seem strange, but there are many languages that do compile, or transpile if you wish, into JavaScript. A large reason for this is simply the fact that JavaScript is a scripting language and was not really designed for large applications so simply does not have some of the language constructs that aid in the creation of larger projects. The later version of ECMAScript (the standard that JavaScript is based on) are attempting to solve that problem, with TypeScript being an example of what the future of JavaScript may be like. The problem, however, is that there are people using old browsers so may not have access to the latest language features. Therefore, tools such as TypeScript are useful as they take new language constructs and compile them into older JavaScript code making the code useful to a broader range of users.

Developing in C or C++ is quite a bit different from using a language like TypeScript that was designed to compile into JavaScript. The reason a person would do this would most likely be to port existing code to the web. In fact, Unreal and Unity are two examples of such uses of this process. In my case, developing in C++ makes some sense as it would give me a very performant version that would run on computers (and possibly Android, IOS however does not allow emulation). The web version would be compiled into asm.js to give it satisfactory performance on browsers that implement asm.js and would still run on browsers that did not support asm.js.

The last sentence may sound contradictory but only if you don’t know what asm.js is. For those of you not sure what I am talking about, asm.js is a subset of JavaScript that can be compiled into very optimized machine language. Browsers that support the standard will then spot the asm.js code and compile it into native machine language for the best speed. Because the subset is designed for optimal code, the result is much faster execution than what JIT compilation would give you. Browsers that are not aware of asm.js would just see perfectly valid JavaScript which it would be able to run, though this would be at JIT speeds so the results would not be as good.

There are a couple of other ways of compiling C++ for use on a web page. The most obvious alternative is Native Client (NaCl) which is Google’s sandboxing technology for allowing native code to run in a browser. This has the advantage that the code being run is already compiled, but needs to be compiled for the processor that the client is using (so multiple versions would need to be created). The bigger issue is that many browser venders are not implementing this so it largely limited to the Chrome browser.

The other alternative is the relatively new WebAssembly bytecode standard. Instead of using a subset of JavaScript, this uses a bytecode compiled version of JavaScript. This results in much more efficient downloading of the application as the bytecode version is smaller than the code version. I find this a fascinating development as what is effectively happening is a replacement of Java bytecode that is vanishing from browsers and replacing it with a new bytecode. It is receiving support from all the major browser vendors but is a relatively new standard. In the future, I may go with WebAssembly for creating web applications, but as it may be a while before older browsers that can’t run it disappear, going with asm.js in the short term makes the most sense. Once I start getting some asm.js material out, I will see how difficult it would be to support both formats.