WebAssembly is the Keystone

Within the last two days, WebAssembly (wasm) has graced the eyeballs of many JavaScript developers. If WebAssembly is new to you, the articles linked at the end of this post fully describe what WebAssembly is. In short, it offers a way to run native code in a Web browser.

I’d like to try to relate WebAssembly to a change Tim Berners-Lee made to the first Web browser…

Meanwhile, I took one quick step that would demonstrate the concept of the Web as a universal, all-encompassing space. I programmed the browser so it could follow links not only to files on HTTP servers, but also to Internet news articles and newgroups. These were not transmitted in the Web's HTTP protocol, but in an Internet protocol called FTP (file transfer protocol). With this move, Internet newsgroups and articles were suddenly available as hypertext pages.

In one fell swoop, a huge amount of the information that was already on the Internet was available on the Web.

This changed how I think about the humble URL. I was initially surprised that Tim saw the URL as the most vital Web technology and chose to have it standardized before HTTP and HTML. The Web has taken over the world because of the power of linking things together, especially things not yet on the Web. Having joined the Internet as a youngster in the late 90s, I entirely missed the pre-Web days, and perhaps needed a reminder that URLs are a Big Deal.

Today, URLs can take us to images, videos, articles, text, PDFs, and much more. Most types of media are linkable. It raises the question: what can’t have a URL?

There’s at least one type of content that still isn’t linkable: Applications. Though not for lack of trying. For the past ten years, the JavaScript revolution has been trying to make real the dream of following a URL to an application.

It’s been a circuitous and partially successful effort. The Web has changed from a network of documents to a network of document/application hybrids. All of the world’s most successful websites make heavy use of client-side JavaScript (with one exception: craigslist). These changes elevated JavaScript to be the most in-demand tech skill¹.

Still, there are classes of applications where the JavaScript tax of dynamism, garbage collection, and runtime is too expensive. Videogames, image and video editing, and CAD are all application genres which do exist in JavaScript, but can’t compete on even footing with their cousins written mostly in C++. These applications simply aren’t at their best when implemented in JavaScript.

Bringing these native applications to the Web (allowing URLs to go directly to them) seems like a worthy goal. And there’s precedent. Emscripten made it possible to “compile to JS”, asm.js made it run faster, and WebAssembly has now taken the step of removing JavaScript from the equation² to unlock even more speed.

My great hope for WebAssembly is that it can bring the world’s teeming vault of existing applications onto the Web, just like Tim-Berners Lee’s act of adding all the world’s newsgroups to the Web.

Imagine using Photoshop merely by going to photoshop.adobe.com, and you’ll have some idea of where WebAssembly might carry us.

Update (2023-10-12): it happened

After the WebAssembly announcement, I read every bit of documentation currently available, about a dozen articles, joined the W3C Community Group, and have been hanging out in the IRC channel (irc://irc.w3.org:6667/#webassembly). I don’t want to speak too soon, but I’m pretty well convinced that WebAssembly is the next revolution.

• The wasm FAQ covers nearly everything
• Luke Wagner’s initial announcement
• Brendan Eich’s practical and lighthearted appeal
• Eric Elliot makes a strong and diverse case
• ArsTechnica brings wasm to a wider audience