Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Open Source / Software Development / WebAssembly

WASI 0.2 Preview: A New Dawn for WebAssembly

The launch of WebAssembly System Interface is poised to redefine the boundaries of web applications and server-side processing.
Jan 26th, 2024 4:33pm by
Featued image for: WASI 0.2 Preview: A New Dawn for WebAssembly

With WebAssembly System Interface 0.2’s arrival, WebAssembly takes a big step toward becoming easier to deploy

In the ever-evolving landscape of web development and application architecture, a significant milestone has been reached with the official launch of WebAssembly System Interface (WASI) 0,2. The project is poised to redefine the boundaries of web applications and server-side processing, promising a future where code portability and security are not just aspirations but realities.

WASI, at its core, is an API designed for WebAssembly (Wasm) that enables it to interact more effectively with the underlying system. This meant that WebAssembly could go beyond the confines of the web browser, venturing into the realms of server-side applications, command-line tools, and even embedded systems, all while maintaining the high level of security and portability Wasm is known for.

The problem was, as Brooks Townsend,  lead software engineer at Cosmonic, observed in a post published Thursday on the wasmCloud blog, “Working with the standard set of WASI interfaces isn’t meant for application developers. They are fundamentally lower levels of abstraction meant for library developers and implementers.

WASI 0.2.0 is important not because it gives application developers the ability to write real things with WebAssembly (we’ve been doing that for four years!), but because it provides a stable definition of common interfaces for library developers in each language.”

For Cosmonic and wasmCloud, this means they’ll update their runtime Wasm Interface Type (WIT) definitions. This will enable developers to build WebAssembly components to work with Rust and TinyGo, along with JavaScript and Python.

Security ‘Baked in’ with WASI

One of WASI’s primary goals is to bridge the gap between the high-performance, sandboxed execution environment of WebAssembly and the diverse functionalities required by real-world applications. This includes access to file systems, network sockets, and other system resources, all within a secure sandboxed environment that mitigates the risks traditionally associated with native code execution.

Security is not an afterthought with WASI; it’s baked into its design’s very fabric. By leveraging the sandboxed nature of WebAssembly, WASI ensures applications can run with minimal permissions, reducing the surface area for potential security vulnerabilities.

It’s also the hope that WASI is getting close to delivering the promise of WebAssembly to deliver near-native performance across different platforms without the need for platform-specific code.

This means developers can write their application once and run it anywhere — from cloud servers to Internet of Things devices — without worrying about the underlying hardware or operating system. Mind you, we’ve been hearing this promise since Java was the hot new technology.

Looking ahead, Townsend wrote in his blog post, “We will see libraries emerge in each language that demonstrates good Wasm component support, and I expect to see something like this for Rust, TinyGo, Python, JavaScript, C/C++, and C# in the near future. We may even see this support built into the standard libraries of these languages.”

All of this means a brighter future for WebAssembly and applications outside the browser.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.