feature article
Subscribe Now

WebAssembly: JavaScript Done Right

New Binary Format is Quicker and Safer than Web Alternatives

“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. 

5 thoughts on “WebAssembly: JavaScript Done Right”

  1. Glad to learn a bit more about WebAssembly. But it seems to me that part of this article is founded on an error: that JavaScript bears a close relationship to Java. The use of “Java” in “JavaScript” was a marketing decision; the languages are not closely related. Wikipedia’s description of the (weak) connection in its JavaScript entry seems on-target: “The final choice of name caused confusion, giving the impression that the language was a spin-off of the Java programming language, and the choice has been characterized as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new Web programming language.” The article goes back and forth between Java and JavaScript in several places in a way that’s misleading. Beyond the intro, if you just stopped talking about Java at all, and substituted “JavaScript” pretty much everywhere you have “Java,” it would probably be more accurate.

    1. Good point. I didn’t mention Java much, but even that was probably unnecessary and, as you point out, confusing. I could fix it, but then both of our comments would look foolish. 😉

  2. “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.” Actually this is not true. Java was meant to map quite easily to hardware and for most part it does (Some native Java CPUs can be found here: https://en.wikipedia.org/wiki/Java_processor). The unfortunate choice was that they based the JavaVM on a stack processor, which can be very light weight (Think of the ZPU soft CPU stack processor, <500 LUTs on a Xilinx FPGA) but did have various other disadvantages crippling adoption.

    1. While there were many attempts to create Java processors/accelerators such as the ones cited in the Wikipedia article, none of them worked very well or gained any kind of commercial success. I think it’s fair to say there are no Java processors, only attempts at Java processors.

Leave a Reply

featured blogs
Jul 5, 2022
By Editorial Team The post Q&A with Luca Amaru, Logic Synthesis Guru and DAC Under-40 Innovators Honoree appeared first on From Silicon To Software....
Jul 1, 2022
We all look for 100% perfection and want to turn our dreams (expectations) into reality as far as we can. Are you also looking for a magic wand to turn expectation into reality? The story applies to... ...
Jun 28, 2022
Watching this video caused me to wander off into the weeds looking at a weird and wonderful collection of wheeled implementations....

featured video

Synopsys USB4 PHY Silicon Correlation with Keysight ADS Simulation

Sponsored by Synopsys

This video features Synopsys USB4 PHY IP showing silicon correlation with IBIS-AMI simulation using Keysight PathWave ADS.

Learn More

featured paper

3 key considerations for your next-generation HMI design

Sponsored by Texas Instruments

Human-Machine Interface (HMI) designs are evolving. Learn about three key design considerations for next-generation HMI and find out how low-cost edge AI, power-efficient processing and advanced display capabilities are paving the way for new human-machine interfaces that are smart, easily deployable, and interactive.

Click to read more

featured chalk talk

Tame the SiC Beast - Unleash the Full Capacity of Silicon Carbide

Sponsored by Mouser Electronics and Microchip

Wide band gap materials such as silicon carbide are revolutionizing the power industry. At the same time, they can also introduce byproducts including overheating, short circuits and over voltage. The question remains: how can we use silicon carbide without those headache-inducing side effects? In this episode of Chalk Talk, Amelia Dalton chats with Rob Weber from Microchip about Microchip’s patented augmented switching technology can make those silicon carbide side effects a thing of the past while reducing our switching losses up to 50% and accelerating our time to market as well.

Click here for more information about the Microsemi / Microchip AgileSwitch® ASDAK+ Augmented Switching™ Dev Kit