From browser brat to backend boss: Will WASM win the web wars?

Opinion Beginning in 1995 and for decades after, JavaScript was the only game worth playing when it came to web-based scripting. While incredibly versatile, JavaScript had its limitations, especially regarding performance-intensive tasks. As the web evolved, so did the demand for more power, speed, and flexibility in web applications. Enter WebAssembly (WASM).

Recognizing the need for a more efficient way to run code in web browsers, the World Wide Web Consortium (W3C) and major browser vendors began working on a new binary format. This format aimed to be fast, efficient, and secure, allowing developers to run code at near-native speed. Thus, in 2015, WASM was introduced as a low-level virtual machine that runs bytecode, which is translated from high-level languages.

Now, WASM is not a programming language per se. Instead it's a compact binary instruction format. Unlike JavaScript, which is interpreted, WASM is a low-level bytecode that runs in a sandboxed environment within the browser, ensuring both speed and security.

Developers love it because they can write code in languages they already know, such as C, C++, and Rust. Web developers were also pleased with it because they didn't need to replace their JavaScript programs. Instead they could call WASM functions from JavaScript and vice versa, allowing for a seamless integration between the two.

At first, WASM was a pure web play. Then things changed. In 2019, Mozilla introduced its WebAssembly System Interface (WASI) to access operating system resources. This broke WebAssembly out of the browser.

Once out of the browser box, it became, as WASM expert and Fastly Director of Engineering Lin Clark put it, "a fast, scalable, secure way to run the same code across all machines."

Does that sound familiar? It should, you could use that same description for containers.  But you don't need to believe me. As Solomon Hykes, Docker co-founder, tweeted at the time: "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link."

More recently, in 2023, the Cloud Native Computing Foundation's (CNCF) head of ecosystem, Taylor Dolezal, said: "WebAssembly is the future because it is increasingly used for serverless, containerization and plug-in technologies and is expected to significantly impact web, serverless, gaming and containerization applications."

Strong words. So is WASM "the future of computing?"

Personally, I've been a cynic about it. While programs such as WASI and competing runtimes such as WasmEdge have made it much easier to run WASM optimized code on the edge and the backend, it strikes me that there's still a lot of work to be done. And I'm not the only one who sees this problem.

As Torsten Volk, Enterprise Management Associates analyst, has said: "There is a lot of ground to cover in terms of reliably and efficiently supporting production use cases." Exactly. 

• A license to trust: Can you rely on 'open source' companies?
• Soon the most popular 'real' desktop will be the Linux desktop
• Meta can call Llama 2 open source as much as it likes, but that doesn't mean it is
• Red Hat's open source rot took root when IBM walked in

For example, Python has become the quick, easy way for people to work with machine learning programs – thank you, PyTorch. But you can't simply drop these programs into WASM in a runtime and expect them to work. The problem is that you also need many third-party dependencies, which aren't there yet.

If WASM continues to rise in popularity, companies and open source groups will do the hard work of building these nuts and bolts.

But, wait, you say – isn't Kubernetes the future? Well, yes, but as Adobe pointed out recently, WASM and Kubernetes can work hand-in-hand. They worked out a way to make a "full microservice, currently running in Kubernetes, and make it run in WASM."

Why? It gave them a more lightweight model that could be almost instantly scaled as traffic rose, giving more scheduling flexibility than a coarse-grained container, while still using Kubernetes to orchestrate everything. With this, Adobe could "securely enable high performance and efficiency, while still being compatible with Kubernetes." It was, for Adobe, the best of both worlds.

Adobe had more resources than most companies to throw at their problems. Looking ahead, though, WASM may become easier for smaller businesses to use on the backend.

That's because of the WebAssembly Component Model (WACM) and WASI-Preview 2.

The former project will incrementally define a component model. This will provide a portable, load and runtime-efficient binary format for separately compiled components built from WASM core modules that enable portable, cross-language composition. It will also provide better support for virtualizable, statically analyzable, capability-safe, language-agnostic interfaces.

The latter is the next version of WASI. This will expand WASI's APIs beyond POSIX to WASI filesystem, HTTP, cloud, and network sockets. It will also provide better bindings for non-C-like languages.

Put it all together, and I think WASM may well finally live up to its potential. Still, there's many a slip between developers' ideas and production code. But the bricks to build practical WASI backend designs are now being fired. By 2025, we'll know if WASM will indeed prove to be the future of backend software development. ®