And this is a good thing, and it should stay this way, cause if WebAssembly got a way to get direct access to your display, input devices or local storage, it would be a breach to the philosophy of WASM to put security first.
Like these legacy plugin technologies, WebAssembly lets you execute compiled binary code in the browser, making it a compile target for many languages. The possibility to compile C and C++ to WebAssembly makes it possible to make use of the enormous universe of libraries written in these languages directly in the web browser. Just to mention one there is for example WASM-GIT which is a port of the popular GIT library libgit2, written in C, working out of the box when compiled to WebAssembly using Emscripten.
So what about writing entire Web Apps in WebAssembly?
- you want to port an existing desktop app to the Web
- you want to port legacy plugin based apps such as Java applets, Flash etc.
- you want to reuse browser-side code on the server
- you need to write your web app in another language
You can port desktop apps to the Web by rendering them in an HTML canvas. I will not go into the details about this, but for example desktop applications built with Qt can be ported this way. There are also examples on Java applets ported successfully, and even Flash.
Blazor, which is a .net runtime ported to WASM running in the browser, makes it possible to write an entire client side Web app in C#. It also enables you use the same C# code on the server. Blazor does not run your code in WebAssembly, it’s only the runtime that is WASM which again runs your .net binaries in the browser. So it wouldn’t give you the same performance as a real WASM binary, the purpose here would rather be to reuse .net binaries. Also there are extra overhead when it comes to size of the web application. In the world of progressive web apps we can limit the amount downloaded to only what’s new, but still the initial application to be downloaded package can be quite massive compared to a similar app in plain HTML / JS.
Speaking of reuse — what about WASM on the server?
WebAssembly on the server is interesting when it comes to running the same code in the browser and on the server, but also for server-side security. The same sandbox that restricts WASM in the browser is also present on the server side. WASM is a good candidate for shipping containers to the cloud, since not only it’s not limited to a CPU architecture, but the container orchestrator would have even more control over capabilities provided to WASM containers, compared to Docker containers.
From my own experience with WASM on the server is the Xapian search index used in Runbox7. I was working with the initial parts of this project that involved running Xapian using WebAssembly both in the browser and on the server. Building the search index for emails server-side, and then transfer the index files to the browser using the same Xapian code on the client-side to search.
WebAssembly is great for where computational performance is essential. It’s also excellent for reusing libraries written in other languages, as well as porting legacy applications to the web. If code-sharing with the server is important, and you want to use another language than JS/TS then such language support can provided by WASM, or if you simply want to write as little JS as possible.
Still JS is the most efficient for controlling the DOM and interacting with Web APIs, and WASM can’t do anything without provisioning of capabilities from JS. And keeping it this way is essential for keeping WASM secure compared to plugin-based predecessors.
How to pronounce WASM btw?