When WebAssembly (Wasm) first appeared in 2017, its mission seemed crystal clear: to give web developers the ability to run high-performance code in a browser. But today, a few years later, we are seeing something unexpected — WebAssembly is rapidly leaving its native habitat and conquering servers, edge devices, and even embedded systems. What's going on?
A problem that no one expected to solve.
Imagine the typical architecture of a modern cloud application. You have microservices in different languages: Go, Node.js, Python, Rust. Each of them requires its own runtime environment, a set of dependencies, and a specific configuration. Deployment turns into a quest, and security becomes a constant headache.
Now imagine that you can compile any of these services into a single, universal format that works everywhere with predictable performance and rock-solid security guarantees. This is exactly what WebAssembly promises outside the browser.
WASI: a bridge to the real world
The key moment in the evolution of WebAssembly was the emergence of WASI (WebAssembly System Interface), a standardized API for interacting with the operating system. If Wasm is a processor, then WASI is its operating system.
// Simple HTTP server on Rust, compiled in Wasm
use wasi::http;
#[no_mangle]
pub extern "C" fn handle_request() -> i32 {
let request = http::incoming_request();
let response = http::outgoing_response();
response.set_status_code(200);
response.body().write(b"Hello from WebAssembly!");
0
}WASI solves a critical problem: how to give Wasm modules access to the file system, network and other system resources, while maintaining the capability-based security model. The module only accesses what is explicitly allowed and nothing more.
Performance that surprises
One of the main advantages of WebAssembly on the server is the launch speed. Traditional containers can start in seconds, the cold start of Lambda functions is measured in hundreds of milliseconds. Wasm module? Microseconds.
These are not just pretty numbers. This is a fundamental change in how we think about scaling:
Docker container:
Cold start time: 1-3 seconds
Volume: 50-500 MB
Isolation: through namespace and cgroups
WebAssembly module:
Cold start time: <1 ms
Size: 1-10 MB
Isolation: built into runtime
Fastly reports that their Compute@Edge platform based on Wasm launches instances in 35 microseconds. Cloudflare Workers achieve similar results. This opens up completely new usage patterns.
Edge computing: a new home for Wasm
Edge computing is where WebAssembly really shines. Imagine a CDN node that not only delivers static content, but executes your business logic as close to the user as possible.
// Cloudflare Worker on AssemblyScript (compiles to Wasm)
export function handleRequest(request: Request): Response {
const url = new URL(request.url);
// Personalization of content on edge
const country = request.headers.get("CF-IPCountry");
const content = getLocalizedContent(country);
// A/B testing
const variant = Math.random() > 0.5 ? "A" : "B";
return new Response(content, {
headers: {
"X-Variant": variant,
"Cache-Control": "public, max-age=60"
}
});
}Thanks to the instant start and minimal overhead, Wasm allows you to run code in thousands of points of presence around the world without crazy infrastructure costs.
Plugins and extensibility.
One of the most exciting applications of WebAssembly outside the browser is the plugin system. The application needs to give users the ability to expand functionality, but how can this be done safely?
Traditional approaches required either running untrusted code in separate processes (slow) or using built-in interpreters (limited). Wasm offers a happy medium:
// The host application on Go loads the user plugin
package main
import (
"github.com/tetratelabs/wazero"
)
func main() {
ctx := context.Background()
runtime := wazero.NewRuntime(ctx)
defer runtime.Close(ctx)
// Uploading plugin from user
plugin, _ := os.ReadFile("user_plugin.wasm")
mod, _ := runtime.InstantiateModuleFromBinary(ctx, plugin)
// Calling a function with resource limits
result, _ := mod.ExportedFunction("process_data").
Call(ctx, data)
}This approach is used by:
Envoy — for custom traffic filters
Shopify — for custom scripts in stores
Figma — for plugins (yes, both on the front and on the backend)
Real cases that impress
Disney+: uses Wasm for server-side image and video processing. One runtime — many processing formats.
Shopify: runs millions of custom scripts per day on Wasm, processing checkout logic for thousands of stores.
Cosmonic: built the entire platform on wasmCloud, where applications can migrate between clouds and edge locations on the fly.
SingleStore: added Wasm to perform custom functions directly in the database — safely and quickly.
Challenges and limitations.
All that glitters is not gold. Server WebAssembly has its own problems:
There is no consensus on WASI yet. The specification is actively developing, different runtimes support different versions. WASI Preview 2 promises stability, but there is no widespread adoption yet.
Debugging is more difficult. Tools for debugging Wasm code on the server are still in development. There are no familiar strace, gdb, or debuggers out of the box.
Ecosystem of libraries. Many popular libraries do not yet support compilation in Wasm or require patches.
Performance is not always better. For CPU-intensive tasks, Wasm can be 10-50% slower than native code. A quick start doesn't always compensate for this.
The time to experiment is right now. Try Wasmtime, play with Spin, and write your first server Wasm module. The future is already here, it's just unevenly distributed.
Code is not just an app, but your personal mentor in the world of programming. It explains everything in simple words, helps to consolidate knowledge in practice and gives cool achievements for success 🏅
And we also have warm and friendly community in telegram, where everyone can ask a question and get an answer - without judgment and unnecessary theory. We solve problems together, analyze mistakes and support each other on the way to the goal.