“The most dangerous tool in the world is a dull knife.” — unknown

Google Earth is pretty cool, right? You can zoom in on any arbitrary point on the planet or watch the scenery zip by as you skim the surface at 1000 feet and 1000 MPH. Check out your neighbor’s backyard pool or circle the Eiffel Tower. It’s all right there in your browser. 

Ever wonder how that works? Streaming an entire globe’s worth of high-resolution photos, elevation data, GIS info, and user-created content into your humble browser obviously involves a USDA boatload of data. Half the web pages out there can barely manage their own annoying pop-up ads; how does Google manage to render the entire #@%$ world? 

One word: WebAssembly. Whereas most pages use some combination of HTML, JavaScript, Perl, Python, and other interpreted scripting languages, Google Earth uses WebAssembly (Wasm for short) to sort of, kind of, run native binary code. Wasm is way faster than anything else, and it brings the web a step closer to becoming an actual application-delivery mechanism, with browsers as universal platforms. 

But, but, but… weren’t Java and JavaScript supposed to do that? Weren’t we promised, “Write once, run anywhere?” Yeah, about that. Java and its accursed offspring are indeed semi-universal but they’re also ungodly slow. Java (as well as JavaScript) enforces a highly idiosyncratic view of the world, one made up of arrays, stacks, objects, garbage collection, runtime validation, function overloading, and other oddities. That worldview was a deliberate choice, and it serves its purpose if you’re into that kind of thing. But Java World is completely different from a C programmer’s world, where memory is one contiguous string of bytes, and garbage collection isn’t a thing. Almost everything is alien. It’s hard to translate C code into Java; it’s hard to even map C-language concepts into Java’s compartmentalized structure.  

More importantly, Java doesn’t map well onto real hardware, either. There are exactly zero CPUs in the world that can execute Java or JavaScript natively. That’s not for lack of trying. They’re simply too radically different. Many hardware startups over the last 20+ years have struggled mightily to create Java processors or even just Java accelerators. The language has stoically resisted all attempts to make itself bearable. 

Enter WebAssembly, a completely different approach to making downloadable apps that run on (almost) any browser. Unlike Java, Wasm takes a C-like (and thus, a hardware-like) view of memory, objects, arrays, and threads. It’s hardware-agnostic, in the sense that it runs on any CPU, not on just one specific instruction-set architecture. It’s also compact and efficient, like assembly language (hence the name). It’s Java for the real world. 

Like most things, WebAssembly came about because programmers were playing games. But JavaScript games were painfully slow, so the developers looked for ways to streamline the process. The first hack was to convert JavaScript’s normal text-only delivery mechanism to a binary download. That speeded up the download process but didn’t do much for execution, which was still mired in Java’s byzantine software architecture. The next big step was to define a new execution model, one that was closer to real hardware and that didn’t rely on Java’s worldview. That turned out to be the big win. 

WebAssembly went semi-official in 2017, and it’s now built into the top browsers, including Chrome, Firefox, Safari, Opera, and Microsoft’s upcoming Chromium-based version of Edge. Because WebAssembly isn’t native to any one machine, it still requires software support in the browser, although its footprint is much smaller than what’s required for JavaScript. Even so, most browser developers reuse some or all of their existing JavaScript engines, treating Wasm almost as a subset of JS. 

One exception is a company called Fastly, a San Francisco-based firm best known for enterprise-level web-acceleration technology. The company wanted to run fast, safe, portable code to inspect and manipulate web pages, but not in a browser. “These need to work in a world where there’s no JavaScript,” says engineer Pat Hickey. Their reasons were twofold: speed and resource requirements. 

Fastly isn’t sharing specifics, but its WebAssembly engine’s memory footprint is measured in kilobytes, not the megabytes typically required for JavaScript. Launching a new Wasm instance takes just microseconds, not milliseconds, on typical edge-node hardware. For Fastly, it was a huge improvement over the default alternative. 

Because WebAssembly is (comparatively) similar to C or assembly, LLVM compilers can now emit Wasm executables, the same way they might target x86, ARM, or any other instruction set. That makes C-to-Wasm programming trivially easy. As a result, hardly anyone writes WebAssembly source code; they simply compile C, C++, Rust, or another favorite LLVM-supported language. Wasm is more like a binary distribution format versus yet another programming language. 

Hickey says that Wasm isn’t just faster than JavaScript, it’s also easier to debug and more secure. JavaScript allows functions to be overloaded and redefined on the fly, a language feature that makes validating JS code extremely complex. Yet this onerous task has to be done at runtime; there’s no way to pre-validate JS code. Wasm code, on the other hand, can be validated in a single pass – and it can be done pre-download by compile-time tools, just like C code. (Browsers still sandbox Wasm code, just as they do with JavaScript or any other downloaded executable.) 

“JavaScript is a very opinionated language and a security nightmare for a VM implementer,” says Hickey, “but the Wasm format allows for easy validation. Everything has a type that can be validated in one simple pass thru the binary.” 

Wasm takes a deliberately simple view of memory and a restrictive attitude toward security. WebAssembly programs can’t manipulate their own stack – a favorite trick of malware authors – nor can they see their own code space. Unlike C programs, Wasm programs can see only their own data space; no self-modifying code allowed. And even though WebAssembly is delivered in binary format, it can still be viewed in text form using a browser’s “view source” feature. 

Unlike Java, WebAssembly isn’t owned by anyone. It’s a classic collaborative effort under the auspices of a W3C community group. Hickey describes the community as “very cooperative,” without any nefarious backroom dealings as one company struggles for control of the specification. Indeed, Google abandoned its own in-house Native Client (NaCl) technology in favor of WebAssembly. 

Which brings us back to Google Earth – and games. Initial versions of the remarkable app were native-only, for the simple reason that they needed to render massive amounts of data quickly and without any noticeable delay. Existing web scripting technologies were never going to cut it. So, Google developed its own language, NaCl, in order to make programs like Google Earth, Doom, Quake, and Tomb Raider work in browsers. NaCl worked fine if you had Chrome, but competing browsers didn’t support it, so the company recently switched to WebAssembly instead. 

Because it’s nearly ubiquitous in browsers, programmers can deploy Wasm content with some reasonable certainty that it will work. Like HTML or JavaScript, Wasm is entirely invisible to the user. Your favorite sites might be using Wasm already; there’s no way to tell without examining the page’s source. Quick, clean, and invisible: exactly the point behind WebAssembly.