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
Mar 18, 2024
Innovation in the AI and supercomputing domains is proceeding at a rapid pace, with each new advancement heralding a future more tightly interwoven with the threads of intelligence and computation. Cadence, with the release of its Millennium Platform, co-optimized with NVIDIA...
Mar 18, 2024
Cloud-based EDA tools are critical to accelerating AI chip design and verification; see how NeuReality leveraged cloud-based chip emulation for their 7NR1 NAPU.The post NeuReality Accelerates 7nm AI Chip Tape-Out with Cloud-Based Emulation appeared first on Chip Design....
Mar 5, 2024
Those clever chaps and chapesses at SiTime recently posted a blog: "Decoding Time: Why Leap Years Are Essential for Precision"...

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured paper

Reduce 3D IC design complexity with early package assembly verification

Sponsored by Siemens Digital Industries Software

Uncover the unique challenges, along with the latest Calibre verification solutions, for 3D IC design in this new technical paper. As 2.5D and 3D ICs redefine the possibilities of semiconductor design, discover how Siemens is leading the way in verifying complex multi-dimensional systems, while shifting verification left to do so earlier in the design process.

Click here to read more

featured chalk talk

Optimize Performance: RF Solutions from PCB to Antenna
Sponsored by Mouser Electronics and Amphenol
RF is a ubiquitous design element found in a large variety of electronic designs today. In this episode of Chalk Talk, Amelia Dalton and Rahul Rajan from Amphenol RF discuss how you can optimize your RF performance through each step of the signal chain. They examine how you can utilize Amphenol’s RF wide range of connectors including solutions for PCBs, board to board RF connectivity, board to panel and more!
May 25, 2023
33,899 views