Guida WebAssembly 2026: Dalle Basi alla Produzione con Rust, C++ e Go

WebAssembly (Wasm) is a binary instruction format designed as a portable compilation target for high-level languages. It enables near-native performance in web browsers and beyond. Since reaching W3C Recommendation status, WebAssembly has become a foundational technology for compute-intensive web applications, server-side runtimes, and edge computing. This guide covers everything from Wasm fundamentals to advanced topics like SIMD, threading, and upcoming proposals.

What Is WebAssembly?

WebAssembly is a binary instruction format for a stack-based virtual machine. It is designed to be a portable compilation target for programming languages, enabling deployment on the web for client and server applications. Wasm code is delivered in a compact binary format (.wasm files) that is decoded and compiled by the browser engine much faster than parsing equivalent JavaScript.

WebAssembly has two representations: the binary format (.wasm) used in production, and the text format (WAT - WebAssembly Text Format) used for debugging and manual inspection. WAT uses S-expressions and is human-readable. Modules are the fundamental unit of Wasm code, containing functions, tables, memory, and globals.

Binary Format (.wasm)

# A compiled Wasm binary header (magic number + version)
00 61 73 6d  # \0asm  (magic number)
01 00 00 00  # version 1

# Wasm uses section-based encoding:
# Section 1  - Type section (function signatures)
# Section 3  - Function section (function declarations)
# Section 7  - Export section (exported names)
# Section 10 - Code section (function bodies)

Text Format (WAT)

(module
  ;; Define a function that adds two i32 values
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add
  )

  ;; Export the function so JavaScript can call it
  (export "add" (func $add))

  ;; Define and export a linear memory (1 page = 64KB)
  (memory (export "memory") 1)

  ;; Global mutable variable
  (global $counter (mut i32) (i32.const 0))
)

Memory Model

WebAssembly uses a linear memory model. Memory is represented as a contiguous, resizable array of bytes. It is allocated in 64KB pages and can be shared between Wasm and JavaScript. The linear memory is bounds-checked at runtime, preventing buffer overflows from escaping the sandbox.

Shared memory (using SharedArrayBuffer) enables multiple Wasm instances or Web Workers to read and write the same memory region. This is essential for multi-threaded Wasm applications. Atomic operations ensure data consistency across threads.

(module
  ;; Declare linear memory: initial 1 page, max 10 pages
  ;; Each page = 64KB (65,536 bytes)
  (memory (export "memory") 1 10)

  ;; Store a 32-bit integer at byte offset 0
  (func $store_value (param $offset i32) (param $value i32)
    local.get $offset
    local.get $value
    i32.store
  )

  ;; Load a 32-bit integer from byte offset
  (func $load_value (param $offset i32) (result i32)
    local.get $offset
    i32.load
  )

  ;; Grow memory by 1 page, returns previous page count or -1
  (func $grow (result i32)
    i32.const 1
    memory.grow
  )
)

Accessing Memory from JavaScript

// Access Wasm linear memory from JavaScript
const memory = instance.exports.memory;

// Create typed views into the memory buffer
const bytes = new Uint8Array(memory.buffer);
const ints = new Int32Array(memory.buffer);
const floats = new Float64Array(memory.buffer);

// Read/write values directly
ints[0] = 42;          // Write i32 at byte offset 0
floats[1] = 3.14159;   // Write f64 at byte offset 8

// Copy a string into Wasm memory
const encoder = new TextEncoder();
const encoded = encoder.encode("Hello, Wasm!");
bytes.set(encoded, 256); // Write at offset 256

// IMPORTANT: views are invalidated when memory grows
instance.exports.grow_memory();
// Must re-create views after growth
const newBytes = new Uint8Array(memory.buffer);

Compiling from Rust

Rust is the most popular language for WebAssembly development thanks to its zero-cost abstractions, lack of a garbage collector, and excellent Wasm tooling. The wasm-pack tool handles building, testing, and publishing Rust-generated Wasm packages. The wasm-bindgen crate provides the bridge between Rust types and JavaScript.

To get started, install the Wasm target and wasm-pack. Create a new library crate and configure it with the cdylib crate type for Wasm output.

# Install the Wasm target for Rust
rustup target add wasm32-unknown-unknown

# Install wasm-pack
cargo install wasm-pack

# Create a new library project
cargo new --lib my-wasm-lib
cd my-wasm-lib

Cargo.toml Configuration

[package]
name = "my-wasm-lib"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2"

[dependencies.web-sys]
version = "0.3"
features = ["console", "Document", "Element", "Window"]

[profile.release]
opt-level = "s"     # Optimize for size
lto = true          # Link-time optimization

Rust Source with wasm-bindgen

use wasm_bindgen::prelude::*;

// Import JavaScript functions
#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);

    #[wasm_bindgen(js_namespace = Math)]
    fn random() -> f64;
}

// Export a greeting function to JavaScript
#[wasm_bindgen]
pub fn greet(name: &str) -> String {
    log(&format!("Hello from Wasm, {}!", name));
    format!("Hello, {}! Random: {:.4}", name, random())
}

// Export a compute-intensive function
#[wasm_bindgen]
pub fn fibonacci(n: u32) -> u64 {
    match n {
        0 => 0,
        1 => 1,
        _ => {
            let (mut a, mut b) = (0u64, 1u64);
            for _ in 2..=n {
                let temp = a + b;
                a = b;
                b = temp;
            }
            b
        }
    }
}

// Working with byte arrays
#[wasm_bindgen]
pub fn sha256_hash(data: &[u8]) -> Vec<u8> {
    // Process byte data from JavaScript
    let mut hash = vec![0u8; 32];
    // ... hashing logic ...
    hash
}

Build and Use

# Build with wasm-pack (generates pkg/ directory)
wasm-pack build --target web --release

# The pkg/ directory contains:
# - my_wasm_lib_bg.wasm  (compiled binary)
# - my_wasm_lib.js       (JS glue code)
# - my_wasm_lib.d.ts     (TypeScript types)
# - package.json         (npm package)

// Using the Rust Wasm module in JavaScript
import init, { greet, fibonacci } from "./pkg/my_wasm_lib.js";

async function main() {
  // Initialize the Wasm module
  await init();

  // Call exported Rust functions
  const message = greet("Developer");
  console.log(message);

  const fib50 = fibonacci(50);
  console.log("fib(50) =", fib50);
}

main();

Compiling from C/C++

Emscripten is the primary toolchain for compiling C and C++ code to WebAssembly. It provides a complete SDK including a compiler (emcc), system libraries, and JavaScript glue code generation. Emscripten can compile large existing codebases including game engines, codecs, and scientific libraries.

The emcc compiler supports various optimization flags. Use -O2 or -O3 for production builds, -g for debug info, and -s flags for Wasm-specific settings like ALLOW_MEMORY_GROWTH and EXPORTED_FUNCTIONS.

// image_filter.c - Example C code for Wasm compilation
#include <emscripten/emscripten.h>
#include <stdint.h>
#include <stdlib.h>

// Export function with EMSCRIPTEN_KEEPALIVE
EMSCRIPTEN_KEEPALIVE
void grayscale(uint8_t* pixels, int length) {
    for (int i = 0; i < length; i += 4) {
        uint8_t r = pixels[i];
        uint8_t g = pixels[i + 1];
        uint8_t b = pixels[i + 2];
        uint8_t gray = (uint8_t)(0.299f * r
                     + 0.587f * g + 0.114f * b);
        pixels[i] = pixels[i+1] = pixels[i+2] = gray;
    }
}

EMSCRIPTEN_KEEPALIVE
uint8_t* create_buffer(int size) {
    return (uint8_t*)malloc(size);
}

EMSCRIPTEN_KEEPALIVE
void destroy_buffer(uint8_t* ptr) {
    free(ptr);
}

# Compile with Emscripten
emcc image_filter.c -o image_filter.js \
  -s WASM=1 \
  -s EXPORTED_FUNCTIONS="[\
    '_grayscale', '_create_buffer', '_destroy_buffer'\
  ]" \
  -s EXPORTED_RUNTIME_METHODS="['ccall','cwrap']" \
  -s ALLOW_MEMORY_GROWTH=1 \
  -O3

# For standalone Wasm (no JS glue):
emcc image_filter.c -o image_filter.wasm \
  -s STANDALONE_WASM=1 \
  -s EXPORTED_FUNCTIONS="['_grayscale']" \
  --no-entry -O3

JavaScript Interop

WebAssembly modules communicate with JavaScript through imports and exports. Exported functions can be called from JavaScript, and imported functions allow Wasm to call back into JavaScript. Data exchange happens through linear memory using TypedArrays for efficient zero-copy access to Wasm memory from JavaScript.

TypedArrays such as Uint8Array, Float32Array, and Int32Array provide views into WebAssembly linear memory. This enables passing complex data structures between JavaScript and Wasm without serialization overhead.

// Loading and instantiating a Wasm module
async function loadWasm() {
  // Method 1: Streaming compilation (preferred)
  const response = await fetch("module.wasm");
  const { instance } = await WebAssembly
    .instantiateStreaming(response, {
      env: {
        // Import: JS function callable from Wasm
        log_value: (value) => console.log("Wasm:", value),
        get_time: () => Date.now(),
      },
      js: {
        mem: new WebAssembly.Memory({
          initial: 1, maximum: 10
        }),
      },
    });

  // Call exported Wasm functions
  const result = instance.exports.add(10, 20);
  console.log("10 + 20 =", result); // 30

  return instance;
}

// Method 2: Module caching with IndexedDB
async function loadCachedWasm() {
  const db = await openDB("wasm-cache", 1);
  let module = await db.get("modules", "myModule");

  if (!module) {
    const response = await fetch("module.wasm");
    module = await WebAssembly
      .compileStreaming(response);
    await db.put("modules", module, "myModule");
  }

  return WebAssembly.instantiate(module, imports);
}

TypedArray Data Exchange

// Passing arrays between JavaScript and Wasm
function processImageData(instance, imageData) {
  const { memory, process_pixels, alloc, dealloc } =
    instance.exports;
  const pixels = imageData.data; // Uint8ClampedArray

  // Allocate memory in Wasm for the pixel data
  const ptr = alloc(pixels.length);

  // Copy pixels into Wasm memory
  const wasmMemory = new Uint8Array(memory.buffer);
  wasmMemory.set(pixels, ptr);

  // Process in Wasm (much faster than JS)
  process_pixels(ptr, pixels.length);

  // Copy results back to JavaScript
  // Re-create view in case memory grew
  const result = new Uint8Array(memory.buffer);
  imageData.data.set(
    result.slice(ptr, ptr + pixels.length)
  );

  // Free Wasm memory
  dealloc(ptr, pixels.length);

  return imageData;
}

WASI (WebAssembly System Interface)

WASI is a modular system interface for WebAssembly that provides POSIX-like APIs for file system access, networking, clocks, random numbers, and more. It enables Wasm modules to run outside the browser in runtimes like Wasmtime, Wasmer, and WasmEdge. WASI uses a capability-based security model where modules only get access to explicitly granted resources.

Popular WASI runtimes include Wasmtime (Bytecode Alliance reference implementation), Wasmer (universal runtime with multiple backends), and WasmEdge (optimized for cloud-native and edge computing). Each supports different WASI proposals and embedding scenarios.

// Rust WASI example: file I/O
use std::fs;
use std::io::Write;

fn main() {
    // Read from stdin
    let mut input = String::new();
    std::io::stdin().read_line(&mut input)
        .expect("Failed to read");

    // Write to a file (pre-opened directory)
    let mut file = fs::File::create("/output/result.txt")
        .expect("Cannot create file");
    write!(file, "Processed: {}", input.trim())
        .expect("Write failed");

    // Read environment variable
    if let Ok(val) = std::env::var("CONFIG_PATH") {
        println!("Config: {}", val);
    }

    println!("WASI module completed successfully");
}

# Compile Rust to WASI target
rustup target add wasm32-wasi
cargo build --target wasm32-wasi --release

# Run with Wasmtime (capability-based access)
wasmtime run \
  --dir /output::/tmp/output \
  --env CONFIG_PATH=/etc/app.conf \
  target/wasm32-wasi/release/my_app.wasm

# Run with Wasmer
wasmer run my_app.wasm --dir /output::/tmp/output

# Run with WasmEdge
wasmedge --dir /output:/tmp/output my_app.wasm

Performance Benchmarks vs JavaScript

WebAssembly consistently outperforms JavaScript for compute-intensive tasks. Benchmarks show Wasm achieving 1.2x to 2x near-native performance for numerical computation, while JavaScript typically runs at 3x to 10x slower than native. The gap is most significant for tight loops, integer arithmetic, and memory-intensive operations.

Performance varies by workload type. For DOM manipulation and string processing, JavaScript may be faster due to the overhead of crossing the Wasm-JS boundary. For cryptography, image processing, physics simulations, and data compression, Wasm provides substantial speedups.

// Performance benchmarking example
async function benchmark() {
  const { instance } = await WebAssembly
    .instantiateStreaming(fetch("bench.wasm"));

  // Warm up
  for (let i = 0; i < 100; i++) {
    instance.exports.fibonacci(40);
  }

  // Wasm benchmark
  const wasmStart = performance.now();
  for (let i = 0; i < 1000; i++) {
    instance.exports.fibonacci(40);
  }
  const wasmTime = performance.now() - wasmStart;

  // JavaScript benchmark
  function jsFib(n) {
    if (n <= 1) return n;
    let a = 0, b = 1;
    for (let i = 2; i <= n; i++) {
      [a, b] = [b, a + b];
    }
    return b;
  }

  const jsStart = performance.now();
  for (let i = 0; i < 1000; i++) jsFib(40);
  const jsTime = performance.now() - jsStart;

  console.log("Wasm:", wasmTime.toFixed(2), "ms");
  console.log("JS:", jsTime.toFixed(2), "ms");
  console.log("Speedup:", (jsTime/wasmTime).toFixed(1)+"x");
}

Use Cases

WebAssembly excels in scenarios requiring high performance, code reuse from other languages, or sandboxed execution. Key use cases include image and video processing (Photon, FFmpeg.wasm), cryptographic operations (libsodium), game engines (Unity, Unreal), audio/video codecs (AV1, Opus), scientific computing (NumPy via Pyodide), CAD applications, and plugin systems.

Threading

WebAssembly threading uses SharedArrayBuffer and Web Workers to enable parallel execution. The threads proposal adds atomic operations and shared linear memory. Wasm threads map to Web Workers in browsers, with each worker instantiating the same Wasm module with shared memory.

Threading requires cross-origin isolation headers (Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp) to enable SharedArrayBuffer. Atomics provide wait/notify primitives for thread synchronization.

// Setting up Wasm threading with Web Workers
// Required HTTP headers for cross-origin isolation:
// Cross-Origin-Opener-Policy: same-origin
// Cross-Origin-Embedder-Policy: require-corp

// Main thread: create shared memory and workers
const sharedMemory = new WebAssembly.Memory({
  initial: 10,
  maximum: 100,
  shared: true,  // Requires SharedArrayBuffer
});

const module = await WebAssembly.compileStreaming(
  fetch("parallel.wasm")
);

// Create worker threads
const NUM_THREADS = navigator.hardwareConcurrency || 4;
const workers = [];

for (let i = 0; i < NUM_THREADS; i++) {
  const worker = new Worker("wasm-worker.js");
  worker.postMessage({
    module,
    memory: sharedMemory,
    threadId: i,
    totalThreads: NUM_THREADS,
  });
  workers.push(worker);
}

// wasm-worker.js - Worker thread
self.onmessage = async (e) => {
  const { module, memory, threadId, totalThreads } = e.data;

  const instance = await WebAssembly.instantiate(module, {
    env: { memory },
  });

  // Each worker processes its portion of data
  instance.exports.process_chunk(
    threadId,
    totalThreads
  );

  self.postMessage({ done: true, threadId });
};

SIMD Instructions

WebAssembly SIMD (Single Instruction, Multiple Data) enables parallel processing of data using 128-bit vectors. It provides operations on packed integers and floating-point values, processing 4 float32 or 2 float64 values simultaneously. SIMD is particularly effective for image processing, audio DSP, matrix operations, and physics simulations.

The fixed-width 128-bit SIMD proposal is supported in all major browsers. Rust exposes SIMD through the std::arch::wasm32 module, while C/C++ uses the wasm_simd128.h header with familiar intrinsics.

// Rust SIMD for WebAssembly
use std::arch::wasm32::*;

// SIMD-accelerated vector addition (f32x4)
#[target_feature(enable = "simd128")]
pub unsafe fn add_vectors_simd(
    a: &[f32], b: &[f32], result: &mut [f32]
) {
    let len = a.len();
    let simd_len = len / 4 * 4; // Process 4 at a time

    for i in (0..simd_len).step_by(4) {
        let va = v128_load(a[i..].as_ptr() as *const v128);
        let vb = v128_load(b[i..].as_ptr() as *const v128);
        let vr = f32x4_add(va, vb);
        v128_store(result[i..].as_mut_ptr() as *mut v128, vr);
    }

    // Handle remaining elements
    for i in simd_len..len {
        result[i] = a[i] + b[i];
    }
}

// C/C++ SIMD with Emscripten
#include <wasm_simd128.h>

// SIMD dot product: 4 multiplies + horizontal add
float dot_product_simd(
    const float* a, const float* b, int n
) {
    v128_t sum = wasm_f32x4_const(0, 0, 0, 0);
    int i;

    for (i = 0; i + 3 < n; i += 4) {
        v128_t va = wasm_v128_load(&a[i]);
        v128_t vb = wasm_v128_load(&b[i]);
        sum = wasm_f32x4_add(
            sum, wasm_f32x4_mul(va, vb)
        );
    }

    // Horizontal sum of the 4 lanes
    float result = wasm_f32x4_extract_lane(sum, 0)
                 + wasm_f32x4_extract_lane(sum, 1)
                 + wasm_f32x4_extract_lane(sum, 2)
                 + wasm_f32x4_extract_lane(sum, 3);

    // Scalar remainder
    for (; i < n; i++) result += a[i] * b[i];

    return result;
}

// Compile: emcc -msimd128 -O3 simd.c -o simd.wasm

Debugging

Chrome DevTools provides native WebAssembly debugging support. You can set breakpoints in WAT or source-mapped high-level languages, inspect linear memory, view the call stack, and step through Wasm instructions. The DWARF debug format enables source-level debugging for C/C++ and Rust.

Additional tools include wasm-tools (inspection, validation, transformation), wasm-objdump (disassembly), wasm-opt from Binaryen (optimization passes), and browser console logging via imported JavaScript functions.

# wasm-tools: Swiss Army knife for Wasm
# Install
cargo install wasm-tools

# Validate a Wasm module
wasm-tools validate module.wasm

# Print module structure
wasm-tools print module.wasm

# Dump section info
wasm-tools dump module.wasm

# Convert WAT to Wasm binary
wasm-tools parse module.wat -o module.wasm

# Strip debug info for production
wasm-tools strip module.wasm -o module.stripped.wasm

# Optimize with Binaryen
wasm-opt -O3 module.wasm -o module.opt.wasm
wasm-opt -Oz module.wasm -o module.small.wasm  # Size

// Debug logging: import console.log into Wasm
const imports = {
  debug: {
    log_i32: (val) => console.log("[wasm i32]", val),
    log_f64: (val) => console.log("[wasm f64]", val),
    log_mem: (ptr, len) => {
      const bytes = new Uint8Array(
        memory.buffer, ptr, len
      );
      console.log("[wasm mem]",
        new TextDecoder().decode(bytes));
    },
    trace: (id) => {
      console.trace("[wasm trace] checkpoint", id);
    },
  },
};

// Chrome DevTools Wasm debugging:
// 1. Open Sources panel
// 2. Find .wasm file in the file tree
// 3. Set breakpoints in WAT disassembly
// 4. Inspect locals, globals, memory in Scope panel
// 5. Enable DWARF for source-level C/Rust debugging:
//    Install "C/C++ DevTools Support" extension

Future Proposals

The WebAssembly ecosystem continues to evolve with several significant proposals in various stages of standardization.

GC (Garbage Collection) Proposal

The GC (Garbage Collection) proposal adds struct, array, and reference types to Wasm, enabling languages with garbage collectors (Java, Kotlin, Dart, Go) to compile to smaller, faster Wasm modules without shipping their own GC runtime.

;; GC proposal: struct and array types in WAT
(type $point (struct
  (field $x f64)
  (field $y f64)
))

(type $points (array (ref $point)))

;; Create a GC-managed struct
(func $make_point (param $x f64) (param $y f64)
                  (result (ref $point))
  (struct.new $point
    (local.get $x)
    (local.get $y)
  )
)

;; Access struct fields
(func $distance (param $p (ref $point)) (result f64)
  (f64.sqrt
    (f64.add
      (f64.mul
        (struct.get $point $x (local.get $p))
        (struct.get $point $x (local.get $p)))
      (f64.mul
        (struct.get $point $y (local.get $p))
        (struct.get $point $y (local.get $p)))))
)

Component Model

The Component Model defines a higher-level module format with rich types, enabling Wasm components to compose with each other and with host environments using typed interfaces (WIT - Wasm Interface Type). This is the foundation for language-agnostic plugin systems.

// WIT (Wasm Interface Type) definition
// image-processor.wit
package example:image-processor@1.0.0;

interface types {
  record image {
    width: u32,
    height: u32,
    pixels: list<u8>,
  }

  enum filter {
    grayscale,
    blur,
    sharpen,
    edge-detect,
  }
}

world image-processor {
  use types.{image, filter};

  export apply-filter: func(
    img: image, f: filter
  ) -> image;
  export resize: func(
    img: image, w: u32, h: u32
  ) -> image;
}

Stack Switching

Stack Switching enables efficient coroutines, async/await, and lightweight green threads in WebAssembly without transforming the source code. This is critical for languages with built-in concurrency models.

Best Practices

1. Minimize Wasm-JS boundary crossings by batching operations and using shared memory.
2. Use wasm-opt from Binaryen to optimize Wasm binaries after compilation.
3. Stream-compile large modules with WebAssembly.compileStreaming() for faster startup.
4. Cache compiled modules in IndexedDB to avoid recompilation on subsequent visits.
5. Profile with browser DevTools to identify whether bottlenecks are in Wasm or in JS interop.
6. Use SIMD for data-parallel workloads like image processing and numerical computation.
7. Enable threading only when needed and ensure cross-origin isolation headers are set.
8. Keep Wasm modules small by excluding unused functions with link-time optimization (LTO).

Frequently Asked Questions