You may have heard about WebAssembly at some point over the past few years. It’s been called “the fourth language of the web browser,” and while that is one way to look at it, it certainly isn’t even close to the whole story. Since  WebAssembly is actually a platform-agnostic binary format for executables, talking about where it runs is just as important as what it does. Over the past year or two, WebAssembly has blown past the browser and is now lending its strengths to other domains such as embedded systems, IoT, and server-side development.

I’ve been working on the cloud native WebAssembly framework  Atmo for about a year now, and the possibilities I laid out here have me very excited about the future of the ecosystem. I see advancements every week, with new open source projects and cool use-cases popping up everywhere.

It’s well known that the past decade has seen the software industry shift from bare metal to virtual machines to containers. The current era has many forms of cloud compute vying for your attention such as Kubernetes, various types of serverless, and more. The problem has become the immense complexity of these solutions — and that doesn’t even begin to cover the need to integrate client-side applications into the mix. WebAssembly is enabling something special, and that is the ability to have reusable modules of code that can be run anywhere, and which can be composed to build powerful software with less complexity.

Let’s cover the basics of WebAssembly; it’s a bytecode format that can be a compilation target for many languages. This simply means that when writing code with Rust, C++, Swift, and more, you can target WebAssembly instead of the executable binary or static library that’s normally produced. The resulting module is language-agnostic and can be executed in a variety of environments. WebAssembly modules are completely sandboxed when they run, meaning that third-party or even potentially unsafe code is less terrifying than your average dependency from NPM or GitHub. It even means that when a WebAssembly module crashes, it doesn’t affect anything outside of its sandbox. WebAssembly can achieve near-native performance (by that I mean faster than JavaScript), and there are a number of different runtime environments both inside and outside the browser to choose from.

#development #contributed #webassembly