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
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 with links to spec and a nice presentation that gives more details about the motivation and mechanics of this extension.

Levels of Testing

I would never expect that I’m so much into test automation. Last few days I watched a crowd of browsers clicking buttons, uploading files and navigating across webpages without even a move of a muscle from my side. That probably have something to do with my passion towards all kind of game bots… or this is an escape from the cruel reality and ugly code of a new project.

I started to read more about testing and automation and I was really confused by the classification of the “levels of testing”. Take “Functional Testing”, “Regression Testing”, “System Testing” and “Acceptance Testing” as examples. They are often described as the different phases and many people tend to post long wordy explanations of how they are different. Well, maybe they are right, but I just see “Blah Blah Blah” and unnecessary overcomplication of a simple idea. Let’s review the sample levels to understand what they really mean.

Levels of Testing

“Functional” describes the testing object – “what” are we testing, the aspect of application that we put under a test. We want to ensure that program works as written in spec – it “functions” properly. Or we check how application reacts on “stress”: a network blackout, or a grenade in a datacenter.

The next question to answer is “Why” are we running a particular test. Do we want to find what is more appropriate: give money for a good work or give a list of bugs to fix? Well, this is an “Acceptance” testing. Do we want to know if have broken something that used to work? Then this is a “Regression” test.

The words living in “why” domain are often mixed up with the words living in “what” domain. The main confusion comes from trying to compare them. It’s like seeking differences between “blue” and “salty”! Moreover this system is described as “levels” – a word that assumes that there is a certain order of components and there are clear borders between them. In my opinion this classification feels much more like a grid with “Why”s on X axis and “What”s on Y axis.

Testing table

“Functional Acceptance Testing” is OK and so is “Stress Regression Testing”. These terms describe both the aspect that being tested AND the purpose of the test. “Are there enough features implemented so that we can accept the product”, “Will we have problems in handling stress situations if we move from MySQL to Cassandra” are the real questions behind the buzzwords. Two-word terms to describe testing approach or phase are extremely missleading. Especially when “Why”s and “What”s are mixed. Using word “level” to describe a grid-like structure only adds the confusion to the subject. Well, I guess pyramids sell better than grids and they are easier for senior management to understand. Kidding of course. Keep it simple and don’t let those terms confuse you!