Four major web browsers now offer experimental builds which leverage WebAssembly – a compiling technology capable of bringing the performance of complicated web output closer to native machine code than even the latest and speediest JavaScript compilers.

Mozilla developer Luke Wagner aggregated the various browser announcements at Mozilla Hacks today, and announced also the availability of a WebAssembly port of Unity’s Angry Bots sci-fi shooter, which can now be played on WA-enabled versions of Chrome, Firefox and Microsoft Edge – with Apple’s WebKit-based Safari browser soon to follow. Microsoft posted a YouTube Video (embedded below) of Angry Bots running on the Chakra rendering engine via WebAssembly in Edge:

(Important: the links to browser downloads above are to experimental and unstable builds. Please don’t download them unless you know what you’re doing.)

angry-bots-gameplay-chrome-canary

I downloaded the WebAssembly-enabled Chrome Canary* preview build, and found the graphic responsiveness of the Unity Angry Bots demo to be eye-opening, even on a not-so-new HP EliteBook

WebAssembly represents a new format for native web applications. It supports all the functionality enabled by the asm.js JavaScript subset, which is itself an effort to cut down on the speed-blocking effect of frameworks and interpreters by allowing application instructions to run as close to the bare-metal processor as possible.

Additionally WebAssembly has been designed not to challenge or supplant JavaScript, which has taken a painful 15-20 years to gain a mature development base accompanied by mainstream applications and innovative APIs, but rather to accommodate it seamlessly whilst allowing more general program direct access to processor instruction-sets – without the overhead of garbage-collection, amongst many other benefits.

The W3C Web Assembly Group was formed last year, with lead participants Google, Microsoft, Apple and Mozilla leading a concerted effort of over 540 other individuals and organisations.

In its own announcement about Microsoft Edge’s implementation of WebAssembly, Chakra Program Manager Limin Zhu notes that the WebAssembly code follows exactly the same pipeline as equivalent asm.js code would after parsing, and observes of the current Angry Bots WA demo: ‘Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case.’

Huge breakthroughs have been made in the performance of JavaScript in the last 10-15 years, not least with the frequently record-breaking rendering of the V8 JavaScript Engine, which also announces its collaboration with WebAssembly today:

‘Two upcoming changes will also significantly improve the developer experience. A standard textual representation of WebAssembly will enable developers to view the source of a WebAssembly binary like any other web script or resource. In addition, the current placeholder Wasm object will be redesigned to provide a more powerful, idiomatic set of methods and properties to instantiate and introspect WebAssembly modules from JavaScript.’

Close to the machine

No code runs faster than machine code, since it corresponds directly to and addresses instructions at a hardware level on the processor, executing directly from the CPU. However it is painful to write and more painful yet to edit, as its files read out as straight binary code – zeroes and ones. Assembly code is text-based and human-readable, with near-native correlation to machine instructions. But a great deal of the code we use – native as well as web programs – relies instead on interpreters, libraries or other intercedents, either at the OS level or via third-party technologies, with concomitant delays varying from lag to outright processing bottlenecks.

The benefit of getting program performance closer to the level of machine code or assembly code performance is the lack of obstructing middle-entities, and many projects have been undertaken, usually as browser plugins, to attempt to make web-content performance ‘code-native’.

Luke Wagner emphasises in his post that WebAssembly has come to unite and not divide:

‘[We] knew it was important for WebAssembly to be “of the Web:” it had to access existing Web APIs and integrate tightly with JavaScript by, e.g., allowing calls between WebAssembly and JavaScript. Unlike classic plugin models, this will allow WebAssembly to be more easily integrated into JavaScript applications and libraries, just as asm.js has been able to do.’

Thanks to accommodation for polyfills, developers will be able to work with WebAssembly prior to popular native implementation. The WebAssembly GitHub Organisation has a loose schedule for the release of a first draft of the WebAssembly binary format, as well as setting out a description and rationale for the initiative. The project also plans to accommodate asynchronous JavaScript function execution, and to provide a wider array of tests in WebAssembly’s test suite.


* My first choice was Firefox Nightly Build, but for some insane reason the developers still let its app ID conflict with standard RTM releases, making it impossible to run your standard Firefox and the Nightly Build at the same time.