Why WebAssembly is a Big Deal
WebAssembly is a technology that every programmer should be watching with interest. It will become more popular. It will replace JavaScript. It will replace HTML and CSS. It will replace mobile phone apps. It will replace your desktop applications. Within 10 years, I guarantee that every programmer will at least need to know how to use tools to manipulate WebAssembly and understand how it works.
“Outrageous!”, you might say. Well, read on.
What is WebAssembly
WebAssembly in it’s current form is a new extension for your web browser that lets it run precompiled code… fast. You write some small routine in C++, then use the Emscripten compiler to compile that code to WebAssembly. With a bit of Javascript glue, you can then invoke that small bit of code in your web browser to, for example, run a particle simulation.
The WebAssembly file itself, with the extension .wasm, is a binary format containing executable instructions. To use the file, you must write an HTML file that runs some Javascript to fetch, compile and execute the WebAssembly file. The WebAssembly file is executed on a stack-based virtual machine, and communicates with its Javascript wrapper using shared memory.
So far, this doesn’t seem interesting. It looks like little more than an accelerator for Javascript. The astute reader will have some inkling of what WebAssembly could become, though.
What will WebAssembly become?
The first big observation I’d like to make here is that WebAssembly is a secure sandboxed virtual machine. You can run your favourite bit of WebAssembly code from the Internet and be mostly assured that it will not take over your PC or server. The four major web browsers are so confident of it’s security that it’s already implemented and enabled by default. How secure it really is remains to be seen, but security is a core design goal of WebAssembly.
My second big observation is that WebAssembly is a universal compile target. It’s original compiler was a C compiler, which is a good indication of how low-level and retargetable the WebAssembly virtual machine is. A lot of programming languages have their virtual machines written in C, some other languages even use C itself as a compilation target.
At this point in time there is a decent list of programming languages that can be compiled to WebAssembly. This list will continue growing for many years to come.
WebAssembly lets you write code in any programming language, and then let other people securely run that code on any platform without installing anything. That, friends, is the start of something beautiful.
The Deployment Problem
Let’s talk about getting your software to your users.
One of the big factors in choosing a programming language for your new project is how your project will be deployed to your customers. Your programmers would love to write the application in Haskell, Python, Visual Basic or some other language depending on what their favourite recreational drugs are. To use their favourite language, they need to compile their application, make some installable package and somehow get it installed on the client’s computers. There are many ways of delivering software — package managers, executable installers, or installation services such as Steam, Apple App Store, Google play or Microsoft store.
Each of those installation mechanisms means pain, varying from a minor ache when installing from an app store, to a cluster headache when a manager has asked you to make some old COBOL code work on his PC.
Deployment is a problem, and it has always been a pain point for developers and system administrators. The programming language we use is closely tied to the platform we are targetting. If large numbers of users are on PCs or mobile devices, we use HTML and Javascript. If the users are Apple mobile device users, we use… er… Swift? (I actually have no idea). If the users are on Android devices, we use Java or Kotlin. If the users are on a real computer and are willing to handle their end of the Deployment Problem, only then do we developers have more choice in the programming language we use.
WebAssembly has the potential to solve the deployment problem.
With WebAssembly, you can write your application in any programming language that can target WebAssembly, and your application will work on any device and any OS with a modern web browser.
The Hardware Monopoly
You want to buy a desktop or laptop computer. What are your options? Well, you have Intel, and you have AMD. It has been a duopoly for years. One thing which is maintaining this duopoly is the fact that the x86 architecture is cross-licensed only between these two companies, and that, usually, pre-compiled code demands the x86 or x86–64 (cough AMD-64) architecture. There are other factors too, such as the fact that it’s *hard* and *expensive* to design the world’s fastest CPU.
WebAssembly is one (of many) technologies that lets you run your code on any platform. If it becomes the next big thing, the hardware market will become commoditised. If your application is compiled to WebAssembly, it will run on anything — x86, ARM, RISC-V, SPARC. Even the OS market will be commoditised; all you need is a browser that supports WebAssembly in order to run even the most demanding applications if your hardware can do it.
Cloud Computing
But wait, there’s more. Cloud computing has been a buzzword around any IT manager’s office for some time now, and WebAssembly can play right into it.
WebAssembly executes in a secure sandbox. A container can be made that can accept and execute WebAssembly modules on a server with very little resource overhead. You do not need to run a full operating system on a virtualised machine for each service you provide. The hosting provider can just provide you with access to a WebAssembly container that you can upload your code to. It could be a raw container where you accept sockets and parse your own HTTP connections, or it could be a full web service container where your WebAssembly module is only expected to process pre-parsed HTTP requests.
This doesn’t exist yet. If anybody wants to become rich, the idea is yours to keep.
Not Cloud Computing
Back on terra firma, WebAssembly is capable enough to replace most of the applications that you locally install on your PC. Already, we have games that have been ported using WebGL (aka OpenGL ES 2.0). I predict that it won’t be long before large applications like LibreOffice are available directly from a website without installation using WebAssembly.
When this is the case, there’s little point in installing applications locally. There is little difference between a locally installed application and a WebAssembly application. Already, a WebAssembly application can interact with you using a screen, keyboard and mouse. It can do graphics in 2-D or with OpenGL and use hardware to decode video streams. It can play and record sound. It can access your webcam. It can use WebSockets. It can store large amounts of data on your local disk using IndexedDB. These are already standard features in your web browser and can all be exposed to WebAssembly using Javascript.
The only area which is currently difficult is that WebAssembly cannot yet access your local filesystem. Well, it can, using file upload dialogues via HTML, but that doesn’t count. Eventually, somebody will create an API for this, and possibly call it something like “WASI”.
“Running applications from the Internet!? Nonsense!”, you say. Well, here’s a text editor implemented using Qt and WebAssembly (and more).
This is a simple example. A complicated example would have been Adobe Premier Pro or Blender running in a WebBrowser. Or consider something like any Steam game to be runnable directly from the web. It sounds like fiction, but there is no technological reason why this won’t eventually happen.
It will come.
Let’s get naked!
Currently, WebAssembly is executed in an environment that includes an HTML and Javascript wrapper. Why not strip these away? With WebAssembly, why even include an HTML renderer and Javascript engine in your browser?
By providing standardised APIs for all the services normally provided by a web browser, you can invent Naked WebAssembly. This is WebAssembly without the HTML and Javascript wrapper around it to manage it. The web page you visit is a .wasm file, which the browser fetches and runs. The browser provides the WebAssembly module with a canvas, event handler and access to all the services the browser provides.
This doesn’t exist yet. If you go directly to a .wasm file now using your web browser, it asks whether you’d like to download it. I’m going by the assumption that some bright spark will design the APIs required and make this work.
The result of this is that the web can now evolve. Websites are no longer limited to HTML, CSS and Javascript. Entirely new document description languages can be created. Entirely new layout engines can be invented. And, most relevant for polyglots like myself, we can choose any programming language we want to implement online services.
Accessibility
But I hear the outcry! What about accessibility!? What about search engines?
Well, I don’t have a good answer for this yet. But I could imagine several technological solutions.
One solution is that we retain the separation of content and presentation. The content is written in a standardised format such as, for example, HTML. The presentation is managed by a WebAssembly application that fetches and displays that content. This allows a web designer to have any arbitrary presentation using any technology he or she wants — no CSS is required, while search engines and users requiring different kinds of accessibility can still access the content.
Keep in mind that many WebAssembly applications aren’t meant to be textually accessible, such as games and many applications. A blind person won’t get much benefit out of an image editor.
Another solution is that we invent an API which can as a WebAssembly module to provide a DOM of what it intends to render on the screen, for consumption either by a screen reader or search engine. Basically there would be two kinds of presentation: one on a graphical canvas, and another that produces structured textual output.
A third solution is to enhance the canvas with metadata that a screen reader or search engine could use. The WebAssembly is executed and content is rendered on a canvas with extra metadata that describes what was rendered. This metadata would include, for example, whether an area on the screen is a menu and what options there are, or whether an area wants textual input, and what the natural ordering (aka the tab order) of the areas on the screen are. Basically, content that was once described in HTML is now described as areas of a canvas with metadata. Again, this is just an idea, and it might suck in practice.
What Could Have Been
In 1995, Sun Microsystems released Java, with Java applets and a whole lot of fanfare. For the first time, a web page could do something more interesting than <marquee> and animated gifs. Developers could make applications run entirely in a user’s web browser… kind of. They were not integrated into the browser, but rather implemented as heavy plug-ins and required an entire JVM to be installed. In 1995, this was not a small installation. The applets also took a while to load and used a lot of memory. With our huge amounts of memory these days, this is no longer a problem, but in the first decade of Java’s life it made the experience tiresome.
Applets were also unreliable. There was no guarantee they would run, especially if the user was using Microsoft’s implementation. They were also insecure, which was the final nail in the coffin.
To the JVM’s credit, other languages eventually evolved to run on the JVM. But now, that boat has sailed.
FutureSplash / Macromedia / Adobe Flash was also a contender, but a proprietary one, in a proprietary format with a proprietary tool set and a proprietary language. I read that they did open up the file format in 2009. Support was eventually removed from browsers as it was a security risk.
The conclusion here is that if you want your technology to exist on everybody’s machines, your security needs to be tight. I sincerely hope that WebAssembly as a standard reacts well to security issues.
What’s Needed?
WebAssembly is still in it’s infancy. It currently runs code fine and the specification is at version 1.0 with a freeze on the binary format. SIMD instruction support is currently being worked on. Multi-threading, via Web Workers, is also being worked on.
Tooling is available, and will continuously improve for the years to come. Browsers already let you peek inside a WebAssembly file. Firefox, at least, lets you view the WebAssembly bytecode, set breakpoints and view the call stack. I hear that browsers also have profiling support.
Language support includes a decent set of languages — C, C++ and Rust are first-class citizens. C#, Go and Lua apparently have stable support. Python, Scala, Ruby, Java and Typescript have experimental support. It might be an arrogant statement, but I truly believe that any language that wants to be relevant in the 21st century needs to be able to compile or run on WebAssembly.
In terms of API support to access external devices, the only API I’m aware of that’s made available to naked WebAssembly is WASI, which allows for the core functionality such as file and stream access to allow WebAssembly to run outside a browser. Otherwise any API that accesses the outside world needs to be implemented in Javascript inside a browser. This allows for almost everything an application needs, except for file access on the local machine, printer access and other novel hardware access such as non-standard bluetooth or USB devices. “Naked WebAssembly” is not a necessary requirement for it’s success; it’s merely a minor optimisation to not require a browser to include support for HTML, CSS or Javascript.
I’m not certain of what would be required to make WebAssembly first-class citizens in a desktop environment. You would need good copy and paste support, drag and drop support, localisation and internationalisation, window management events and the ability to create notifications. Perhaps these are already possible from a web browser; often I’m surprised by what is already possible.
The spark that will cause the explosion is the creation of environments that allow existing applications to be ported. If a “Linux subsystem for WebAssembly” is made, then a huge amount of existing open source software can be ported to WebAssembly. It would need to emulate a filesystem — which could be done by having all the read-only parts of the filesystem be cached HTTP requests, and all the writable parts be either in-memory, remotely stored or using whatever file access a browser can provide. Graphical support can be done by porting an implementation of X11 or Wayland to use WebGL (which I understand already exists as AIGLX?).
Some SDL games have already been ported to WebAssembly — most notably the official demo.
Once a JVM runs inside WebAssembly, a huge amount of Java software can run in a browser. Ditto for other virtual machines and the languages that use them.
As with the huge world of Windows software, I have no answer. WINE and ReactOS both require an underlying x86 or x86–64 machine, so the only option would be to get the source code and port it, or use an [x86 emulator](https://copy.sh/v86/).
So then…
WebAssembly is coming. It is coming slowly, but all the pieces are now available on the browser you’re using right now. Now we wait while infrastructure for targetting WebAssembly from various programming languages is built. Once built, we will be freed from the tyranny of HTML, CSS and Javascript.
