All three vendors are showcasing an early preview of experimental WebAssembly backing in an AngryBots demo. The previews will run on an internal Microsoft Edge browser build, Mozilla's Firefox, and Google's Chrome. Work on WebAssembly is also proceeding via WebKit, Apple's JavaScript engine for the Safari browser.

"I'm excited to announce that WebAssembly has reached an important milestone: there are now multiple, interoperable experimental browser implementations," Mozilla's Luke Wagner, a research engineer, said." We still have a lot of work left on the standard implementation before shipping, but this is a good occasion to present our progress so far, talk about what's coming next, and invite feedback."

A Microsoft official lauded the performance WebAssembly is offering. "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," Microsoft's Limin Zhu, program manager for the Chakra JavaScript engine, said.

Microsoft's WebAssembly plans depend heavily on ChakraCore. "With ChakraCore now open source, we have been developing our WebAssembly implementation entirely in the open in the WebAssembly branch of our ChakraCore repo on GitHub," Zhu said. "Under the hood, our implementation is able to reuse much of the existing asm.js infrastructure. The WebAssembly code goes through the same pipeline as the asm.js code would, after it has been parsed."

In Google's case, the company is offering experimental support for WebAssembly in its V8 JavaScript engine and the Chromium open source browser, according to the V8 blog. "Under the hood, the WebAssembly implementation in V8 is designed to reuse much of the existing JavaScript virtual machine infrastructure, specifically the TurboFan compiler," said Seth Thompson, who cites his title as WebAssembly wrangler. "A specialized WebAssembly decoder validates modules by checking types, local variable indices, function references, return values, and control flow structure in a single pass."

WebAssembly, Thompson explained, is encoded in a compact binary format and executes at near-native speed in a memory-safe sandbox. "As an evolution of existing technologies, WebAssembly is tightly integrated with the Web platform, as well as faster to download over the network and faster to instantiate than asm.js, a low-level subset of JavaScript."

"The V8/WebAssembly team looks forward to continued collaboration with other browser vendors and the greater community as we work toward a stable release of the runtime," said Thompson. "We're also planning future WebAssembly features (including multi-threading, dynamic linking, and GC / first-class DOM integration) and continuing the development of toolchains for compiling C, C++, and other languages via the WebAssembly LLVM backend and Emscripten."

Thompson said that other upcoming changes will improve the developer experience. The list includes a standard textual representation for viewing the source in a WebAssemby binary, and a planned redesign of a wasm object to provide a more powerful idiomatic set of methods and properties for instantiating WebAssembly modules from JavaScript.

Mozilla plans to add WebAssembly support to Firefox devtools, including the debugger and profiler, as well as further reduction of cold load time and a full set of WebAssembly operators. The World Wide Web Consortium community group working on the project also plans define the official WebAssembly text format, reduce the binary size, and iterate on the WebAssembly JavaScript API, said Wagner, who participates in the group.