JavaScript is no longer the only language that can be run natively in browsers. WebAssembly is set to revolutionize the way you code for the web, allowing native apps to be ported to the browser with near-native performance.

What Exactly Is WebAssembly?

JavaScript is a fully interpreted language. When you connect to a website, they send over the JavaScript code for you to execute. Usually it’s minified (white spaces and line breaks are removed to save space), but you can open up the Chrome dev tools and read the source code directly. While JavaScript is quite fast nowadays, it still needs to be interpreted by the JS engine, which can take a while to parse and adds a lot of overhead. Plus, JavaScript isn’t exactly performant from the get-go.

WebAssembly, often abbreviated as Wasm, isn’t really a “language” that you are going to be writing by hand. It’s a binary-instruction format designed to be faster than JavaScript and very close to compiled languages. It’s still an interpreted language, but it’s designed to be interpreted by machines, not humans.

Because Wasm was designed from the ground up, it’s built with performance in mind. It strips away the complex prototyping from JS, and introduces proper primitives. JS only has floats for numbers—every math operation in JS is done using floats, even though float math is much slower and unnecessary in most cases. Wasm provides primitives for ints, and provides byte-level access to memory. It has a textual representation called WebAssembly Text (.wat), which you can use to code in directly. You’ll always be packaging it up in its binary format for use on the web. Under the hood, Wasm runs on a stack-based virtual machine, which translates the instructions to actual code that runs on your machine.

Because it’s just an instruction format, the magic of Wasm is that it can be used as a portable compilation target for other languages, without sacrificing on speed like you would have with transpiling. This includes languages like C++ and Rust, which can now run on the web when compiled to Wasm.

If your mind was just blown, this isn’t theoretical—it actually works in practice. AutoDesk was able to port AutoCAD, a 30-year-old C++ codebase, over to a WebAssembly-based web app, in a few months, with relative ease. Native apps being ported to the web is a major-use case for Wasm, and we’ll start seeing more apps taking this approach as Wasm pushes what’s possible in the browser.

If you want a cool demo of Wasm’s power, you’ve probably already had it—Google Earth runs in Wasm, rendering complex 3D models with seamless LoD levels and loading as you fly around the planet, all at a perfectly smooth 60 FPS. This simply isn’t possible with JavaScript.

If you want to get started working with Wasm, you can head over to an online WebAssembly playground to try it out.

Is Wasm Going to Replace JavaScript?

No. JavaScript still remains a fantastic language, and with NPM usage soaring past all other language package managers, it’s not going away anytime soon.

Modern JavaScript engines like V8 are still fairly fast, and while it’s not going to allow the same kind of native performance that Wasm brings, it’s still acceptable for most basic web apps and simple scripts that don’t need to do massive data crunching. Essentially, you wouldn’t use Wasm for basic scripting on your website. Triggering an alert when a user presses a button, for example, is easily done by JS, doesn’t need to be performant enough to run a million times per second, and certainly doesn’t need to be written in C.

JS is also much more accessible, as proven by the success of client-side JS frameworks like React. Web apps built with React are still quite fast, and with good render optimization can run at 60 FPS without jank on most smartphones.

However, when you speed and want to run a desktop app in a browser, Wasm is going to become the format of choice. Even still, JavaScript is still required to even call Wasm methods, and you’re still going to be using it in a Wasm codebase.

Wasm on the Desktop

This seems a bit counterintuitive at first, but Wasm running on the server is much more reasonable than you would think. WASI, or WebAssembly System Interface, standardizes how Wasm interacts with the system, and provides a modular environment for WebAssembly to do all of its magic outside of the browser, either on your desktop or in a server environment. With WASI, developers can write the same app for native and web, without resorting to running more instances of Chrome with Electron.

In a sense, this replaces much of what Docker accomplishes. The founder of Docker, Solomon Hykes, has even said so. Code written in any language (which makes this different from .NET/JVM) can probably compile to Wasm, and be ran on any server using WASI. It abstracts away the code from the machine (no more compiling for a specific CPU or OS), and simply requires WASI to be compiled and installed on the machine it runs on. Though Docker isn’t going away either, and in the future it may be able to run Linux, Windows, and WASI containers side-by-side.

This is similar to the promise made by Java—the runtime environment will run the same code on a Windows host or a Linux host. The selling point of Wasm, however, is that you don’t have to program in Java, and are free to choose more performant languages such as C++ and Rust.