WebAssembly: A Foundation for a Higher Performance Web
As the Internet fills a larger role in our lives, more and more is being asked of web applications. JavaScript cannot always provide the necessary performance, so a new solution is required. WebAssembly seeks to fill that position. It is not a new programming language to write in, but is a bytecode format that other languages can be compiled into. Instead of compiling a C++ program to x86 instructions, a developer would compile that same program to WebAssembly instructions. That WebAssembly code can then be shipped and will run on any major browser. This provides several benefits:
- Compile-time optimization: The compiler has a full view of the system at compile time, so it can aggressively optimize the output instructions. This is in contrast to JavaScript, which is interpreted and therefore cannot be optimized as heavily.
- Simplified porting: WebAssembly is a compilation target, similar to x86 or ARM. This means that existing applications and libraries can be ported to WebAssembly just as easily as porting them to any other target. Entire C++ applications can be ported to WebAssembly to run in a browser at near-native speeds, with very little rewriting of the application code.
- Smaller code size: JavaScript is a text format and the code sent to a browser is just a minified text file. WebAssembly is a binary format which is a more efficient way to encode data than text. According to this article from Mozilla, compiled WebAssembly can be less than half the size of compressed JavaScript.
WebAssembly versus JavaScript
A lot of languages have been created to try and improve or fix Javascript. TypeScript adds static typing, CoffeeScript adds some nicer syntax, the list goes on. However, before being run in the browser, these languages need to be transpiled to JavaScript. This means that for all the improvements these new languages make, they are still bound by the same constraints as JavaScript is. On the other hand, WebAssembly is in itself a compilation target. It never gets turned into JavaScript. WebAssembly runs in the browser as WebAssembly, and so it is not constrained by JavaScript’s baggage.
An important item to note about WebAssembly is that it is not trying to supplant JavaScript. WebAssembly has been designed to work alongside JavaScript and provide high performance in the browser when needed. An example of this is the file compression on DropBox. When a user uploads a file, the majority of the code that executes is still JavaScript. However, the step that compresses the file is a compute heavy task that JavaScript would struggle with. To prevent a bottleneck, a WebAssembly module was written to handle the compression task. That WebAssembly code is called from the JavaScript portion like any other library.
Use cases
The use case for WebAssembly is a spectrum. At one end, you have individual modules used from within JavaScript in order to handle specific functions. The earlier example of the DropBox compression component being reimplemented as a WebAssembly module demonstrates this low end of the spectrum. At the other end of the spectrum lies traditionally native applications like AutoCAD and SketchUp. These are large applications that require higher performance than JavaScript can offer. Even if JavaScript was up to the task, the entire application would need to be rewritten in order to run in the browser. With WebAssembly, both are now available in the browser, and neither had to be significantly rewritten.
Porting applications to WebAssembly
One of the advantages of WebAssembly being a compilation target is that existing applications don’t need to be entirely rewritten to be ported to the web. In fact, porting a Windows application to WebAssembly is supposed to be about as difficult as porting that same application to Linux. If an application is written in a language that supports WebAssembly, then most of the core components can be converted directly to WebAssembly modules. The biggest component that cannot be converted is the UI. However, if the application is already cross-platform, then the UI is most likely already abstracted from the core components in a way that allows for easy replacement. This means that basically all non-UI components can be easily ported to WebAssembly. For example, when AutoCAD was ported to WebAssembly, upwards of 95% of the existing codebase could be ported directly.
Implications
WebAssembly has the potential to be a disruptive force in web development. Finally, web developers are gaining access to a more complete share of the resources modern computers have to offer. So far only version 1.0 has shipped, and that has already allowed large native applications like AutoCAD to be ported to the browser. As WebAssembly improves and is more widely adopted, we should all be enjoying a faster, more powerful, web.
