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
Apr 16, 2024
In today's semiconductor era, every minute, you always look for the opportunity to enhance your skills and learning growth and want to keep up to date with the technology. This could mean you would also like to get hold of the small concepts behind the complex chip desig...
Apr 11, 2024
See how Achronix used our physical verification tools to accelerate the SoC design and verification flow, boosting chip design productivity w/ cloud-based EDA.The post Achronix Achieves 5X Faster Physical Verification for Full SoC Within Budget with Synopsys Cloud appeared ...
Mar 30, 2024
Join me on a brief stream-of-consciousness tour to see what it's like to live inside (what I laughingly call) my mind...

featured video

MaxLinear Integrates Analog & Digital Design in One Chip with Cadence 3D Solvers

Sponsored by Cadence Design Systems

MaxLinear has the unique capability of integrating analog and digital design on the same chip. Because of this, the team developed some interesting technology in the communication space. In the optical infrastructure domain, they created the first fully integrated 5nm CMOS PAM4 DSP. All their products solve critical communication and high-frequency analysis challenges.

Learn more about how MaxLinear is using Cadence’s Clarity 3D Solver and EMX Planar 3D Solver in their design process.

featured chalk talk

Using the Vishay IHLE® to Mitigate Radiated EMI
Sponsored by Mouser Electronics and Vishay
EMI mitigation is an important design concern for a lot of different electronic systems designs. In this episode of Chalk Talk, Amelia Dalton and Tim Shafer from Vishay explore how Vishay’s IHLE power inductors can reduce radiated EMI. They also examine how the composition of these inductors can support the mitigation of EMI and how you can get started using Vishay’s IHLE® High Current Inductors in your next design.
Dec 4, 2023