The state of WebAssembly in 2022
Reading time: 4 minutes
When WebAssembly (Wasm) launched in 2017, there was a massive hype around it; people called it the next step in web development. As the exposure grew, the open-source community began to generate a lot of support and tooling for it. The decentralized nature of the community makes it challenging to track Wasm’s current state, so this blog post will recap its evolution over the past five years and what WebAssembly has developed into in 2022.
What languages can get compiled to Wasm?
Although developers can technically type in the
.wat text format, it's not common because many languages support Wasm as a compilation target.
Rust was the first language to support Wasm this way, followed by C/C++ with the help of Emscripten. Other languages include Golang, which has tinygo that supports WebAssembly; C#/.net, from Microsoft, with the introduction of Blazor WebAssembly; and Flutter, from Google, which uses WebAssembly to generate its PWAs (Progressive Web Applications).
Later, higher-level languages followed — like AssemblyScript, which is very similar to TypeScript syntax. Other languages, including Python, Ruby, Java, and Swift, are still in the making. You can find the complete list of languages in this repo.
Initial use cases
Reusing your code written in other programming languages on the web has never been easier. By compiling your existing code to Wasm, all you'll need to do is plug it into your client-side web app.
WebAssembly offers a sandboxed, memory-safe execution environment that can provide security for regulated apps or executing third-party code.
Its near-native performance, and the ability to to run the full applications on the client-side without sending data over the network, opens the web to a whole lot of new possibilities, including compressing and securely decompressing files for the user; image and video manipulation; rendering and converting file types; streaming apps; and even VR and augmented reality.
What has happened since 2017
Shortly after, Unity released its official support to export content as web apps, leveraging Emscripten to convert C/C++ code to WebAssembly and run it in the browser. The Unity team concluded, "Wasm is faster, smaller, and more memory-efficient than asm.js, which are all pain points of the Unity WebGL export."
If you don't know asm.js, Mozilla introduced it in 2013 to run C apps in the browser. Many apps were using it before WebAssembly, but most of them switched to Wasm already. Read more
With many WebAssembly run times like Wasmtime by Mozilla, Wasmer, Lucet by Fastly, WebAssembly Micro Runtime (WAMR), and others already supporting WASI, it enables real portability and security – some of WebAssembly’s core features. This standard opened the door to Wasm beyond the browser, making it possible to build cross-platform apps using WebAssembly and running Wasm code on the edge cloud, becoming a viable and lightweight alternative to containerization or IoT.
In mid-2019, Google Earth released its Beta version of the app using WebAssembly. Previously, they had compiled their C++ codebase to a web app using Native Client (NACI), which only worked on Google Chrome since it was the only browser that supported NACI. After switching to WebAssembly, their app is now accessible across all modern browsers.
In May 2021, Microsoft released Blazor WebAssembly after its long-time implementation of Blazor Server. Using WebAssembly, apps that were written in C# can run on the client-side as a single-page application; they can also be paired with ASP.NET Core to enable full-stack web development with .NET.
“Blazor WebAssembly is .NET running on WebAssembly, so you can re-use code and libraries from server-side parts of your application. Using WebAssembly will also ensure that your current developers who are experienced with .NET will be able to work in the new environment without extensive retraining.” Read the blog
AssemblyScript was released in late 2019, offering TypeScript Developers a very shallow learning curve to write code that could get compiled to Wasm, which led to the launch of WebAssembly Studio, a WebAssembly IDE in the browser.
When it comes to debugging, Google Chrome currently provides the best experience by far — it started with limited support, allowing developers to analyze individual instructions, view the stack trace, or log something.
Later, with the help of Emscripten, it supported DWARF, the standard debugging format supported by many native languages. This enables source Maps debugging, stepping over the native code and adding breakpoints.
WebAssembly’s latest developments didn’t get the marketing it deserves. It’s still a huge breakthrough that is changing the way we think about the web, as it enables running applications in the browser — and the edge cloud — that were previously not feasible.
WebAssembly is also expanding outside of the browser, opening its unique set of capabilities, such as sandboxing, for other ecosystems. It seems like everyone is excited about Wasm, but there is the impression that it’s still in its early stages. That’s not entirely true. WebAssembly isn’t mature, and there are still some caveats to fill as seen in the official roadmap, but it is ready for prime-time for certain use-cases.
WebAssembly is seeing a lot of movement. Very soon, as things speed up, WebAssembly will reach a state mature enough to become a viable solution for a wider array of today’s problems.