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
Nov 29, 2023
Cavitation poses a formidable challenge to modern boat design, especially for high-speed sailing vessels participating in events like America's Cup , Vendee Globe , and Route du Rhum . Hydrofoils, in particular, are susceptible to cavitation, which can cause surface dama...
Nov 27, 2023
See how we're harnessing generative AI throughout our suite of EDA tools with Synopsys.AI Copilot, the world's first GenAI capability for chip design.The post Meet Synopsys.ai Copilot, Industry's First GenAI Capability for Chip Design appeared first on Chip Design....
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

TDK CLT32 power inductors for ADAS and AD power management

Sponsored by TDK

Review the top 3 FAQs (Frequently Asked Questions) regarding TDK’s CLT32 power inductors. Learn why these tiny power inductors address the most demanding reliability challenges of ADAS and AD power management.

Click here for more information

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

While there is great interest in 3D-IC technology, it is still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this paper to learn about design challenges, ecosystem requirements, and needed solutions. While various types of multi-die packages have been available for many years, this paper focuses on 3D integration and packaging of multiple stacked dies.

Click to read more

featured chalk talk

VITA RF Product Portfolio: Enabling An OpenVPX World
Interoperability is a very valuable aspect of military and aerospace electronic designs and is a cornerstone to VITA, OpenVPX and SOSA. In this episode of Chalk Talk, Amelia Dalton and Eddie Alexander from Amphenol SV explore Amphenol SV’s portfolio of VITA RF solutions. They also examine the role that SOSA plays in the development of military and aerospace systems and how you can utilize Amphenol SV’s VITA RF solutions in your next design.
Oct 25, 2023