A WebAssembly Milestone: Experimental Support in Multiple Browsers

WebAssembly is an emerging standard whose goal is to define a safe, portable, size- and load-time efficient binary compiler target which offers near-native performance—a virtual CPU for the Web. WebAssembly is being developed in a W3C Community Group (CG) whose members include Mozilla, Microsoft, Google and Apple.

I’m excited to announce that WebAssembly has reached an important milestone: there are now multiple, interoperable, experimental browser implementations. 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.

Why WebAssembly?

The low-level asm.js subset of JavaScript has demonstrated not only that it’s possible for browsers to achieve safe, sandboxed, near-native computational performance, but that there’s tremendous demand for this kind of capability on the Web. Thanks to the Emscripten compiler, we’ve seen asm.js used for a diverse and growing array of applications, including mapping, cryptography, compression, games, CAD, image editing, and facial recognition.

The WebAssembly CG formed last year to take the Web the next step further, with a standardized binary format whose storage size and decoding times could be optimized beyond what is possible with JavaScript. Additionally, by being a new standard, WebAssembly is able to evolve to accommodate low-level features independently of the evolution of JavaScript.

At the same time, 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.

Finally, we’ve been able to draw on our years1,2,3,4,5,6,7 of experience with Emscripten and asm.js to guide and focus the initial design of WebAssembly. And crucially, with the great performance of asm.js code on modern browsers, the creation of polyfills will allow developers to begin using WebAssembly even before native implementations have reached saturation in the browser market.

Progress

Fast forward to today, and the CG has already made a remarkable amount of progress. Within the WebAssembly GitHub organization, the group has produced:

What’s more, engineers on four browser engines have implemented prototype WebAssembly implementations1,2,3,4. Within Firefox, we refactored our existing asm.js optimization pipeline to use WebAssembly’s binary format as the representation of asm.js code sent from the main parsing thread to the background compiler threads.

This change ended up significantly improving asm.js parallel compilation performance by moving two costly steps, MIR and code generation, off the sequential critical path. With this refactored pipeline, native WebAssembly decoding only requires the addition of a small new frontend to validate the untrusted bytes:

asm.js and WebAssembly compilation pipeline

For definitions of these terms and more background on JS and asm.js compilation, see this previous blog post.

Experimenting with WebAssembly

With all these pieces in place, it’s now possible to build WebAssembly demos that run on multiple experimental implementations. We do mean “experimental”: both the binary format and JS bindings for WebAssembly will likely change incompatibly over the next months until the first edition is stabilized. And we don’t expect implementations to be mature enough for stress tests or benchmarking for some time yet. Rather, the importance of this milestone is getting all the browsers on the same page so we can continue to iterate in sync.

With all that said, it’s gratifying for us to see a real, working demo that will run in multiple browsers:

Screenshot of AngryBots

This particular demo actually has some nostalgic value: AngryBots is a Unity tutorial project which was used as a smoke test while bringing up Unity’s WebGL export. Good memories! :)

To run the demo, download a Nightly build, open about:config and set javascript.options.wasm to true.

Path To Release

So what’s next? There’s more to do before we have a stable, shippable first edition. In the CG, some big remaining tasks are:

  • Define the official WebAssembly text format.
  • Further reduce binary format size. While the current binary format is 42% smaller than asm.js uncompressed (12% smaller after gzip), we know from previous prototype binary format work that further significant size reductions are available.
  • Iterate on the WebAssembly JavaScript API. Currently the experimental builds define a single new synchronous function, Wasm.instantiateModule, that does both compilation and instantiation. There are tentative plans to break these steps apart and provide both synchronous and asynchronous functions that produce a structured-cloneable code object. This gives developers more control over both compilation and machine-code caching than current implicit machine-code caching for asm.js in Firefox.
  • Create more approachable documentation for compiler writers, tool authors, hackers, and students.
  • Add a bunch more tests to the test suite.

In Firefox we’re also planning to:

  • Add WebAssembly support to browser devtools, including both the debugger and profiler. Fortunately, the JavaScript, Developer Tools and Firebug teams worked together to move tools over to a new, abstract, unit-testable Debugger API which we’ll be implementing for WebAssembly code. In fact, work has already begun which is why, if you open the Debugger tab for the above demo, you can already see a placeholder text format being generated for the binary code (which will, of course, switch over to the official text format when it’s ready).
  • Further reduce cold load time. Measuring AngryBots compile time on a 16×2.4Ghz core Linux desktop, WebAssembly reduces compile time by about 52%. That’s a good start and leverages the fact that WebAssembly decoding is currently about 10× faster than asm.js parsing, but cold load time can be significantly further reduced by working on the other parts of the compilation pipeline.
  • Finish adding the full set of WebAssembly operators and import the test suite.

Full Speed Ahead

The progress on WebAssembly so far has been exhilarating. I continue to be impressed and appreciative of the collaborative atmosphere of the whole WebAssembly Community Group. If you want to learn more, the GitHub org page is a good starting point. Happy hacking!

About Luke Wagner

Luke Wagner is a Mozilla software engineer and hacks on JavaScript and WebAssembly in Firefox.

More articles by Luke Wagner…


14 comments

  1. jiyinyiyong

    Since WebAssembly is still in the progress of standlizing its text forma, I want to ask if there’s anyone interested in an indentation based syntax derived from lisp syntax. Demos here:

    http://cirru.org
    https://gist.github.com/jiyinyiyong/0fc58e2ed7c641973d9b
    https://github.com/Cirru/?utf8=%E2%9C%93&query=wasm

    March 15th, 2016 at 08:09

    1. Luke Wagner

      That’s certainly an interesting possibility to consider. The proposal and discussion of the text format will be happening in the github.com/webassembly/design repo and you’re welcome to participate.

      March 15th, 2016 at 10:38

    2. niutech

      Oh no, please not Lisp and its parentheses (((((hell)))))!

      March 16th, 2016 at 19:47

  2. ITfind

    Wow… it’s so nice!
    In my opinion we need to wait around 3-5 years for full browsers support and almost done project.

    March 15th, 2016 at 11:11

  3. BrianMB

    > Iterate on the WebAssembly JavaScript API.

    On this topic, I assumed wasm modules would be compatible with ES6 Modules. Is that not true?

    March 15th, 2016 at 12:15

    1. Luke Wagner

      That is indeed the intention and we’ve designed wasm module imports/exports to integrate the overall ES6 module loader pipeline. First, though, we need to fully spec and land the ES6 module browser integration; that work is underway in Firefox in bug 1240072.

      March 15th, 2016 at 16:12

      1. BrianMB

        Ah, that’s all great. Thanks!!

        March 15th, 2016 at 23:51

  4. rick

    hmm ..your article doesn’t format on IE 11.

    March 16th, 2016 at 07:53

    1. Edge

      Good thing IE11 doesn’t exist.

      March 17th, 2016 at 02:59

      1. niutech

        What? IE11 exists: https://en.wikipedia.org/wiki/Internet_Explorer_11

        April 6th, 2016 at 08:04

  5. IPv6

    Fantastic! Finally web will be really able to replace whole bunch of native applications.

    March 16th, 2016 at 08:23

  6. andkai

    Hello, excuse me, can you tell me the Wa there are tools? So, convenient to me to study? In a recent study this piece, you hope to get your help, thank you.

    March 23rd, 2016 at 04:21

  7. sbo

    Hi, any chance to contribute to the project? I’ve 15yrs programming experience.

    March 29th, 2016 at 01:28

  8. Dave Boyle

    “…getting all the browsers on the same page.” You made a funny :-)

    April 9th, 2016 at 12:55

Comments are closed for this article.