Wasm chegou em 2017 prometendo "código nativo no browser". Em 2026, virou portable runtime: edge functions, plugins, sandboxing seguro, processamento near-native em browser e servidor. Devs ainda confundem com "alternativa a JS no front", mas o uso real está em edge runtimes (Cloudflare, Fastly), em libs heavy (Figma, AutoCAD Web, FFmpeg.wasm), em plug-in systems (Envoy filters, Suborbital).
Este módulo é Wasm como engenheiro full-stack precisa: arquitetura, linear memory, instâncias, bindings, WASI (Wasm fora do browser), Component Model, runtimes (browser, wasmtime, Wasmer, edge). Construir 1 use case real onde Wasm vence outras opções.
2. Teoria Hard
2.1 O que é Wasm
Standard W3C. Bytecode estruturado, tipado, executável em sandbox. Compile target pra Rust, C/C++, Go, AssemblyScript, Zig, etc.
Características:
Portable: roda em browser e fora.
Fast: near-native (compilado JIT/AOT).
Safe: sandbox memory; sem syscalls direto.
Compact: binário pequeno comparado a JS minified.
Não substitui JS em UI, Wasm não tem DOM access direto. Vence em cálculo intenso delegated.
2.2 Linear memory
Wasm module tem memory: array contíguo de bytes. Lê/escreve via instructions. Sem heap typed: você gerencia malloc/free no nível alto (Rust faz transparente).
JS interop: WebAssembly.Memory é ArrayBuffer compartilhada. Funções Wasm recebem pointers (u32) que são offsets na memory. JS escreve dados na memory antes da call, lê depois.
Visão: ecossistema "npm pra Wasm" agnóstico de linguagem. Em 2026, ainda em maturação; Spin/Fermyon/Bytecode Alliance liderando.
2.11 Performance expectations
Wasm é tipicamente:
Startup: ms a sub-ms.
Throughput: 80-110% de native otimizado (cargo --release vs Wasm cargo, é fechado).
JS interop: cada call cross-boundary é ~10s ns. Loop apertado de small calls é caro; move dados em batch.
Pra cálculos com data passing pequeno, Wasm vence JS por 5-50x. Pra workloads dominados por DOM ou string manipulation, JS pode vencer (engine V8 já é otimizada pra isso).
2.12 Debugging
DevTools: source maps Wasm (Rust → Wasm com debug info funcional).
console.log via imports.
wasmtime profiling.
Tracing: tracing crate em Rust mais OTel.
2.13 Bundle e size
LTO (lto = true em Cargo.toml).
opt-level = "z" minimiza tamanho.
wasm-opt (binaryen) post-process.
Strip debug.
Avoid alloc onde possível (#![no_std] em alguns casos).
Meta: módulos Wasm úteis em 50 KB - 500 KB. Big libs (FFmpeg.wasm) 20+ MB.
2.14 Limitações atuais
Threads via SharedArrayBuffer exigem CORS/COEP headers (browser).
SIMD parcial (Wasm SIMD 128-bit).
GC integrado em maturação (WasmGC, default Chrome 119+).
Tail calls, exception handling proposals em progresso.
2.15 Quando Wasm é certo
Hot path de cálculo (parsing, encoding, encryption).
Algoritmo já em C/C++/Rust que você quer no browser.
Plug-in system multi-tenant.
Edge runtime com cold start critical.
Polyglot serverless.
2.16 Quando Wasm é errado
App típico de UI: JS resolve.
Backend regular: Node/Go já entrega.
Equipe sem competência Rust/C: complexidade não compensa.
3. Threshold de Maestria
Você precisa, sem consultar:
Explicar linear memory e como JS↔Wasm troca dados.
Distinguir Wasm browser e WASI.
Justificar Wasm em edge runtime vs Lambda.
Toolchain pra Rust → Wasm pra browser.
Diferenciar wasm-bindgen, wasm-pack, wit-bindgen.
Component Model em uma frase.
3 use cases típicos onde Wasm é certo.
Cost de cross-boundary call e implicação.
Tamanho típico de módulo útil + técnicas pra reduzir.
2 limitações atuais (threads, GC, exceptions).
4. Desafio de Engenharia
Adicionar routing engine Wasm ao Logística, reuso da 03-11 Rust em browser e edge.
Especificação
Compile do 03-11 routing engine pra Wasm:
Adicione target wasm32-unknown-unknown (browser) e wasm32-wasi (server).
wasm-bindgen pra browser bindings.
Output 2 artefatos: .wasm + JS glue.
Use case 1: client-side preview:
Lojista cria pedidos rapidamente em batch e quer preview de roteamento sem chamar backend.
Front Next carrega Wasm dinamicamente.
Calcula routes localmente em < 100ms pra 30 stops.
Mostra mapa preview.
Use case 2: edge function (Cloudflare Worker ou Fastly):
Endpoint edge /route/preview que executa Wasm e retorna routes.
Latência p50 < 50ms global.
Sem cold start observável.
Performance:
Compare 3 implementações:
Backend Node calculando em JS.
Backend chamando Rust binary (via HTTP, do 03-11).
Edge Wasm.
Reportar p50/p95/p99 de cada.
Bundle:
Reduzir Wasm pra ≤ 200 KB gzipped (lto, opt-level=z, wasm-opt).
Lazy load (não no initial bundle).
Memory passing:
Demonstre passar struct grande (lista de stops) por Wasm memory diretamente, evitando JSON serialização.
Compare custo com versão JSON.
Testes:
Property-based tests no algoritmo (no Rust core).
Integration test do binding JS → Wasm.
Restrições
Sem usar lib pronta de routing.
Sem trazer FFmpeg-style monstro de runtime.
Tamanho final do Wasm ≤ 250 KB gz.
Threshold
README documenta:
Diagrama: mesmo Rust core em backend, browser, edge.
Tamanhos finais (Wasm bytes raw, gzipped, brotli).
Tabela latência das 3 implementações.
Demo do preview client-side.
Demo do edge function.
1 lição sobre limitação Wasm que você bateu (threads, async, debugging).