WebAssembly no desenvolvimento web moderno: além do JavaScript

Por mais de duas décadas o JavaScript foi a linguagem incontestada da web, mas o ambiente de execução do navegador já não é monolíngue. O WebAssembly se tornou, discretamente, o segundo tempo de execução de todo navegador moderno, e viabiliza capacidades que o JavaScript sozinho não entrega com eficiência. Editores de imagem, codecs de vídeo, motores de banco de dados, renderizadores 3D, tempos de execução de linguagens: tudo isso já roda dentro de abas do navegador, compilado para um formato binário de baixo nível que atinge velocidade quase nativa.

WebAssembly é um formato binário de instruções de baixo nível executado por uma máquina virtual baseada em pilha. Foi projetado como alvo de compilação portátil para linguagens de programação, permitindo a implantação na web de aplicações de cliente e de servidor. Os quatro fabricantes de navegadores — Google, Mozilla, Apple e Microsoft — colaboraram no projeto, e em 2019 ele se tornou padrão do W3C. Todos os navegadores importantes o suportam desde 2017.

Mas o WebAssembly não substitui o JavaScript: complementa-o. O JavaScript continua sendo a linguagem da manipulação do DOM, do tratamento de eventos e da lógica de interface. O WebAssembly cuida do trabalho intensivo em processamento para o qual o JavaScript nunca foi projetado. Os dois tempos de execução convivem na mesma aba: os módulos importam funções JavaScript e o JavaScript chama as exportações do Wasm por uma API bem definida.

O WebAssembly não pretende substituir o JavaScript. Pretende resolver os problemas que o JavaScript não consegue resolver com eficiência. A plataforma web sai mais forte porque os desenvolvedores podem escolher a ferramenta certa para cada tarefa dentro da mesma aplicação.

Os módulos WebAssembly usam um formato binário (arquivos .wasm) projetado para análise rápida e transmissão enxuta. O formato é compacto: um módulo típico é bem menor do que o JavaScript equivalente, mesmo minificado. Ele codifica tipos, funções, importações, exportações, declarações de memória e instruções em uma representação densa que os navegadores validam e compilam em uma única passagem linear.

Todo módulo WebAssembly opera sobre uma máquina de pilha conceitual. As instruções empilham valores numa pilha de avaliação e os desempilham para realizar operações. Os tipos de valor suportados são i32, i64, f32 e f64: inteiros e números de ponto flutuante de 32 e 64 bits. No nível do Wasm não há cadeias de caracteres, objetos, vetores nem qualquer outro tipo de alto nível. Toda estrutura de dados complexa precisa ser representada na memória linear como bytes brutos.

A memória linear é o conceito mais importante do WebAssembly. Cada módulo pode declarar um ou mais blocos de memória contígua e redimensionável. Essa memória é um vetor plano de bytes que o módulo lê e escreve por instruções de carga e armazenamento. O hospedeiro — o tempo de execução do JavaScript ou o do Wasm — controla o tamanho inicial e o máximo e pode fazê-la crescer pedindo páginas adicionais de 65.536 bytes cada. Do lado do hospedeiro, essa memória é acessível como um ArrayBuffer, de modo que o JavaScript lê e escreve exatamente a memória usada pelo módulo.

É esse modelo de memória compartilhada que torna o WebAssembly eficiente. Hospedeiro e módulo trocam dados sem serialização e sem cópia: simplesmente escrevem no mesmo buffer. Quando uma função Rust devolve uma cadeia ao JavaScript, ela grava os bytes na memória linear e retorna um ponteiro (um deslocamento inteiro) e um comprimento. O JavaScript lê esses bytes diretamente do ArrayBuffer. Sem análise de JSON, sem troca de mensagens, sem custo além da própria chamada.

Estrutura do módulo e validação

Um módulo WebAssembly é composto de seções: a de tipos define as assinaturas das funções, a de funções as declara, a de código contém o bytecode, a de memória define a memória linear e a de exportações disponibiliza funções e memória ao hospedeiro. Antes de qualquer execução, o navegador valida o módulo estruturalmente e impõe segurança de tipos. A validação garante que todos os operandos correspondem aos tipos esperados, que todas as chamadas referenciam assinaturas válidas e que todos os acessos à memória ficam dentro dos limites declarados. Leva milissegundos e garante que um módulo malformado não consiga explorar o tempo de execução.

O modelo de segurança é explícito e restrito. Um módulo WebAssembly não pode acessar o DOM, fazer requisições de rede, ler arquivos ou interagir com o sistema, a menos que o hospedeiro conceda essas capacidades explicitamente por funções importadas. O módulo opera em um confinamento sem acesso a nada fora de sua memória linear e de sua tabela de funções importadas. Isso torna seguro executar módulos vindos de fontes não confiáveis — propriedade decisiva tanto no navegador quanto no servidor.

A qualidade da compilação para WebAssembly varia bastante conforme a linguagem. Algumas produzem módulos enxutos e eficientes, com pouquíssimo custo adicional. Outras exigem um tempo de execução que acrescenta megabytes ao binário. A escolha da linguagem de origem depende dos seus requisitos de desempenho, da experiência da equipe e da complexidade da integração necessária.

Rust: a referência para Wasm

O Rust tem o melhor suporte a WebAssembly entre todas as linguagens. A cadeia de ferramentas wasm-pack cuida sem atritos da compilação, da otimização e da geração das ligações com JavaScript. O Rust produz binários pequenos porque não tem coletor de lixo nem tempo de execução pesado, e seu modelo de posse mapeia naturalmente a gestão de memória linear. Um módulo típico com algumas funções exportadas fica entre 10 KB e 50 KB após LTO e otimização, valor competitivo com Wasm escrito à mão.

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn fibonacci(n: u32) -> u32 {
    match n {
        0 => 0,
        1 => 1,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

#[wasm_bindgen]
pub fn greet(name: &str) -> String {
    format!("Hello, {}! Wasm says hello.", name)
}

O crate wasm_bindgen gera o código de ligação em JavaScript que cuida automaticamente da dança da memória linear. Chamar fibonacci a partir do JavaScript se parece com qualquer outra chamada. Nos bastidores, o wasm_bindgen traduz parâmetros de cadeia em pares ponteiro-comprimento, invoca a função Wasm e converte o resultado de volta em cadeia JavaScript. Essa camada de abstração custa muito pouco e torna a integração Rust-Wasm prática no dia a dia.

C e C++ via Emscripten

O Emscripten é a cadeia de compilação original para Wasm. Ele compila código C e C++ usando LLVM como backend e oferece uma ampla camada de compatibilidade POSIX que permite portar aplicações nativas existentes para a web com alterações mínimas no código-fonte. Inclui um sistema de arquivos virtual, tradução de OpenGL para WebGL, emulação de pthread e um tempo de execução em JavaScript que cuida do ciclo de vida do módulo.

Go com o backend oficial de Wasm

O Go passou a suportar WebAssembly na versão 1.11 e vem melhorando a cada lançamento. Compilar um programa Go para Wasm é simples: define-se GOOS=js GOARCH=wasm e executa-se go build. Contudo, o suporte do Go tem limites claros diante do Rust. O Go inclui seu tempo de execução (escalonador de goroutines, coletor de lixo, pilha de defer) em cada binário, de modo que um módulo mínimo começa em torno de 2 MB. É aceitável no servidor, onde o tamanho importa menos, mas proibitivo no navegador, onde tempo de download e de análise são críticos.

Zig: o novo concorrente

O Zig se apresenta como substituto moderno do C, com suporte de primeira classe a WebAssembly. Seu compilador pode ter o Wasm como alvo diretamente, sem invólucros como o Emscripten. Produz módulos competitivos com o Rust em tamanho e desempenho, e seu recurso comptime permite metaprogramação capaz de eliminar por completo o custo em tempo de execução. O Zig não carrega nenhum tempo de execução oculto — sem coletor de lixo, sem alocador, sem código de inicialização — a menos que você ligue um explicitamente.

• O Rust produz os menores binários Wasm (10-50 KB em módulos típicos) e tem o melhor ecossistema de ferramentas, com wasm-pack e wasm-bindgen.
• C e C++ via Emscripten são a melhor escolha para portar bases de código nativas existentes: máxima compatibilidade, porém binários maiores.
• O Go compila para Wasm com facilidade, mas gera binários grandes (acima de 2 MB) por causa do tempo de execução incluído, o que o torna mais adequado a Wasm no servidor.
• O Zig produz módulos enxutos, sem custo de tempo de execução, e é ideal para usos mínimos e embarcados.

Carregar e executar um módulo WebAssembly no navegador segue uma API padrão, idêntica em todos os navegadores modernos. A API JavaScript expõe no espaço de nomes WebAssembly as funções compile, instantiate e instantiateStreaming. A variante em fluxo é preferível porque começa a compilar enquanto os bytes ainda estão sendo baixados, sobrepondo a entrada/saída de rede à compilação.

async function loadWasm(url: string) {
  const response = await fetch(url);
  const results = await WebAssembly.instantiateStreaming(response);
  return results.instance.exports;
}

async function main() {
  const wasm = await loadWasm("/fibonacci.wasm");
  console.log(wasm.fibonacci(40));
}

main().catch(console.error);

instantiateStreaming devolve um objeto com a propriedade instance (a instância compilada do módulo) e um objeto exports com todas as funções e a memória declaradas como exportações. Também é possível passar um objeto imports como segundo argumento, dando ao módulo acesso às funções e valores JavaScript que ele esperava ao ser compilado.

Em produção, costuma-se pré-compilar o módulo na etapa de construção ou usar um plugin do empacotador. O Webpack 5 suporta importações de Wasm nativamente e o Vite tem suporte experimental. Esses empacotadores cuidam automaticamente do download, da instanciação e do ciclo de vida, permitindo importar módulos Wasm como se fossem módulos JavaScript. Com o wasm-pack, o padrão de importação é import init from './pkg/fibonacci.js', que devolve uma função de inicialização baseada em promessa responsável por todo o código de ligação.

Um ponto crítico no navegador é a compilação inicial. Os módulos são compilados do formato binário para código nativo no primeiro carregamento. Em módulos pequenos são poucos milissegundos. Em módulos grandes — acima de 10 MB — podem ser várias centenas de milissegundos, chegando a bloquear a thread principal. A solução é usar WebAssembly.compileStreaming dentro de um Web Worker: a compilação ocorre fora da thread principal e devolve um objeto de módulo compilado que a thread principal instancia de imediato. Esse padrão é indispensável em aplicações que carregam módulos grandes.

O WebAssembly nasceu pensado exclusivamente para o navegador, mas seu modelo de segurança e suas características de desempenho o tornam igualmente atraente no servidor. A dificuldade é que o navegador fornece APIs de hospedeiro específicas — DOM, fetch, WebSocket — ausentes em ambientes de servidor. A WebAssembly System Interface resolve isso definindo um conjunto padrão de chamadas de sistema no estilo POSIX que os módulos podem usar fora do navegador.

A WASI oferece abstrações para entrada/saída de arquivos, rede, acesso ao relógio, geração de números aleatórios, variáveis de ambiente e argumentos de linha de comando. Um módulo compilado com suporte a WASI pode ler arquivos, abrir soquetes de rede e interagir com o sistema operacional por uma interface normalizada que funciona em qualquer tempo de execução compatível. É essa a base para rodar Wasm como aplicação de servidor.

O padrão WASI evolui por instantâneos sucessivos. A WASI preview 1 é a base estável suportada hoje pela maioria das cadeias de ferramentas. A WASI preview 2 introduz um desenho alinhado ao modelo de componentes, com segurança baseada em capacidades, em que cada módulo declara explicitamente de quais recursos do sistema precisa. A preview 2 é um avanço arquitetural relevante porque viabiliza permissões de granularidade fina: um módulo que só precisa ler um arquivo específico não alcança nenhum outro arquivo do sistema.

A WASI transforma o WebAssembly de tecnologia de navegador em um tempo de execução isolado e universal. O mesmo módulo que roda numa aba pode rodar num tempo de execução Wasm no servidor, numa função sem servidor ou num nó de borda — sem modificação. «Escreva uma vez, execute em qualquer lugar» ganha outro sentido quando esse lugar inclui ambientes que o JavaScript não alcança.

Executar WebAssembly fora do navegador exige um tempo de execução de servidor. Existem vários maduros, com filosofias de projeto e usos distintos. Os três mais importantes são Wasmtime, Wasmer e WAMR (WebAssembly Micro Runtime) para sistemas embarcados.

Wasmtime

O Wasmtime é um tempo de execução autônomo desenvolvido pela Bytecode Alliance, a mesma organização que conduz o padrão WASI. É escrito em Rust, compila os módulos com Cranelift (um gerador de código projetado especificamente para Wasm) e oferece APIs em Rust, C, Python e outras linguagens. É o mais usado para Wasm no servidor e está por trás do Cloudflare Workers, do Fastly Compute@Edge e de outras plataformas de computação de borda.

use wasmtime::*;

fn main() -> Result<()> {
    let engine = Engine::default();
    let module = Module::from_file(&engine, "hello.wasm")?;
    let mut store = Store::new(&engine, ());
    let instance = Instance::new(&mut store, &module, &[])?;

    let hello = instance
        .get_typed_func::<(), ()>(&mut store, "hello")?;
    hello.call(&mut store, ())?;

    Ok(())
}

A API de incorporação do Wasmtime é limpa e idiomática. Cria-se um Engine (o ambiente de compilação), carrega-se um Module de um arquivo ou de bytes, cria-se um Store (o contexto de execução que guarda a memória linear) e instancia-se o módulo para acessar suas funções exportadas. O tempo de execução cuida sozinho de gestão de memória, tratamento de traps e encaminhamento das chamadas de sistema WASI.

Wasmer

O Wasmer é outro tempo de execução bastante usado, que suporta vários backends de compilação: Cranelift, LLVM e Singlepass (compilação JIT rápida, com otimização mínima). Oferece SDKs para Rust, C, C++, Python, Go, PHP, Ruby, Java e outros, o que o torna acessível de praticamente qualquer ambiente. Também disponibiliza um registro de pacotes (WAPM) para distribuir módulos Wasm, à maneira do npm.

A diferença essencial é que o Wasmer prioriza a experiência do desenvolvedor e a facilidade de incorporação, enquanto o Wasmtime prioriza a conformidade ao padrão e a segurança. Ambos são ótimas escolhas; a sua dependerá do que valoriza mais: a amplitude do ecossistema (Wasmer) ou a conformidade estrita à especificação e o histórico em produção (Wasmtime).

• Wasmtime: melhor para Wasm de servidor em produção, conformidade estrita com WASI, compilador JIT Cranelift, usado por Cloudflare e Fastly.
• Wasmer: melhor para incorporar Wasm em aplicações que não são em Rust, suporta compilação com LLVM para velocidade quase nativa e conta com o ecossistema de pacotes WAPM.
• WAMR: melhor para IoT e dispositivos embarcados, pegada mínima, modos interpretador e JIT, com a ferramenta de linha de comando iwasm.

A vantagem de desempenho do WebAssembly sobre o JavaScript depende da carga de trabalho. Em operações limitadas pela CPU e intensivas em cálculo, o Wasm costuma rodar de 1,5 a 3 vezes mais rápido. Em operações intensivas em memória, como processamento de imagens ou compressão, a vantagem pode ser maior porque o Wasm controla diretamente o arranjo da memória e os padrões de alocação. Em cargas dominadas por entrada/saída ou pelo DOM, o Wasm não oferece vantagem e pode até acrescentar custo por causa da ponte entre o módulo e o hospedeiro JavaScript.

O modelo de compilação também pesa. O JavaScript usa compilação JIT: o código começa a executar de imediato e os caminhos quentes são otimizados com o tempo. O Wasm é compilado com antecedência ou no carregamento do módulo, de modo que atinge o desempenho máximo logo de início: não há período de aquecimento. Em funções de vida curta ou execuções únicas, isso elimina o atraso de aquecimento do JIT que pode deixar o JavaScript mais lento na primeira invocação.

É na previsibilidade que o Wasm realmente se destaca. A otimização JIT do JavaScript não é determinística: a mesma função pode ser otimizada ou desotimizada conforme os tipos recebidos, o número de chamadas e o estado das heurísticas do compilador. A execução do Wasm é determinística. Cada instrução tem custo fixo. Não há pausas de coleta de lixo, nem confusão de tipos, nem abandono de otimizações. Isso faz do Wasm a escolha certa quando a constância da latência importa mais do que o pico teórico de vazão: processamento de áudio, simulação física, cálculos financeiros.

• O Wasm vence em: processamento de imagem e vídeo, síntese e análise de áudio, compressão e descompressão de dados, operações criptográficas, motores de jogo, simulações físicas, execução de consultas de banco de dados.
• O JavaScript vence em: manipulação do DOM, tratamento de eventos, orquestração de requisições de rede, renderização de interface com frameworks, processamento de cadeias e texto, utilitários pequenos ou pouco chamados.
• A fronteira se move: à medida que o Wasm ganha acesso a APIs web via WASI e o modelo de componentes, mais cargas migram para ele, mas o JavaScript continua sendo a camada principal de interface.

O modelo de componentes do WebAssembly é a evolução mais significativa desde o lançamento inicial. Ele ataca a limitação de fundo do Wasm inicial: módulos isolados, sem uma forma padronizada de se interligarem. O modelo de componentes introduz um sistema de interfaces de alto nível e independente de linguagem, que permite compor módulos como peças de construção.

No modelo atual, um módulo exporta funções que só recebem e devolvem inteiros e números de ponto flutuante. Se um módulo precisa passar uma cadeia, um vetor ou uma estrutura complexa a outro, os dois têm de concordar com uma convenção de arranjo de memória: compartilhar uma região de memória linear e coordenar alocação e liberação. Isso é frágil e específico de cada linguagem. O modelo de componentes resolve definindo um sistema normalizado de tipos de interface que lida com cadeias, registros, variantes, listas e estruturas aninhadas através das fronteiras entre módulos.

Os tipos de interface descrevem, de forma independente de linguagem, os dados que circulam entre componentes. Um componente pode exportar uma função que recebe uma cadeia e devolve um registro com dois campos inteiros, e qualquer outro componente — escrito em Rust, C ou Go — pode chamá-la sem saber nada sobre o arranjo interno de memória do outro. O tempo de execução gera automaticamente a lógica de adaptação e traduz entre a representação de quem chama e a de quem responde.

O WebAssembly não é uma tecnologia teórica. Ele move algumas das aplicações web mais exigentes hoje em produção, e sua adoção acelera à medida que o ferramental amadurece e os ganhos de desempenho se tornam inegáveis.

Figma: o pioneiro do Wasm

O Figma é o caso de sucesso mais conhecido. Seu motor de renderização é escrito em C++ e compilado para Wasm com o Emscripten. O Figma compila toda a base de código C++ — incluindo a biblioteca gráfica Skia, o moldador de texto HarfBuzz e seu próprio motor de layout — em um módulo Wasm. A camada JavaScript cuida dos eventos de entrada e do DOM, enquanto o Wasm assume toda a renderização, a detecção de cliques e os cálculos de layout. O resultado é uma ferramenta de design que roda numa aba com desempenho comparável ao de uma aplicação nativa de desktop.

SQLite: banco de dados no navegador

O SQLite é provavelmente o módulo Wasm mais implantado do mundo. O projeto publica uma build oficial que executa o motor completo no navegador. Os usuários podem consultar um banco inteiramente do lado do cliente, sem componente de servidor. A build é produzida com o Emscripten e inclui suporte a sistema de arquivos virtual para persistir bancos no IndexedDB.

As implicações são consideráveis. Aplicações que precisam de capacidade de consulta no cliente — ferramentas de análise, painéis de relatórios, cadernos de computação científica — podem usar o SQLite em Wasm para executar agregações complexas, junções e funções de janela diretamente no navegador, sem enviar dados a um servidor. Bibliotecas como sql.js e better-sqlite3-wasm envolvem o módulo em APIs JavaScript limpas e o tornam tão cômodo quanto qualquer pacote npm.

Google Earth: Wasm para renderização 3D

O Google Earth para navegadores foi reconstruído com Wasm para suas esteiras de processamento de terreno 3D e descompressão de dados. Enquanto o usuário navega, o módulo recebe dados binários comprimidos, descomprime-os com algoritmos C++ otimizados e compilados para Wasm, converte a geometria em malhas renderizáveis e entrega o resultado ao WebGL — tudo dentro do orçamento de um único quadro de animação e sem qualquer custo de cópia de dados.

• O Figma usa Wasm no seu motor de renderização em C++ e alcança desempenho de classe nativa na edição de gráficos vetoriais dentro do navegador.
• O SQLite publica uma build oficial em Wasm que executa o motor completo no cliente, viabilizando consultas offline sem servidor.
• O Google Earth apoia-se em Wasm para descompressão em tempo real e processamento geométrico de dados geoespaciais em fluxo a 60 quadros por segundo.
• A Adobe usa Wasm no Photoshop para web (com código C++ compilado pelo Emscripten) para filtros de imagem e conversões de espaço de cor.
• O Zoom usa Wasm no cliente web para decodificação de vídeo e desfoque de fundo.

As plataformas sem servidor adotaram o WebAssembly como tempo de execução na borda por sua vantagem na partida a frio diante dos contêineres. Um módulo Wasm inicia em microssegundos — não em milissegundos — porque não há sistema operacional para iniciar, nem processo para bifurcar, nem tempo de execução para inicializar. Onde a latência de partida a frio afeta diretamente a experiência de uso, isso muda tudo.

O Cloudflare Workers foi a primeira grande plataforma a abraçar o Wasm. Os Workers rodam em isolados do V8 capazes de executar tanto JavaScript quanto módulos Wasm. Um Worker que delega a lógica de cálculo a um módulo pode começar a atender requisições em menos de 5 milissegundos a partir da partida a frio. O ambiente oferece um conjunto limitado de APIs baseadas na especificação de Service Worker — fetch, Cache, armazenamento KV e Durable Objects — e os módulos compilados com suporte a WASI podem usá-las pelo mecanismo de importação do hospedeiro.

O Compute@Edge da Fastly usa o Wasmtime como tempo de execução central e exige que todo cálculo seja compilado para Wasm. Os desenvolvedores escrevem a lógica de borda em Rust, Go ou JavaScript (que a Fastly compila antecipadamente para Wasm), e o módulo resultante roda nos nós de borda da Fastly. Esse modelo oferece isolamento de segurança sólido — cada requisição roda numa instância nova, sem estado compartilhado — junto com a velocidade de partida que torna a computação de borda viável.

O ecossistema de Wasm na borda ainda é jovem, mas cresce rápido. Plataformas como Fermyon Spin e Deislabs oferecem arcabouços pensados especificamente para construir aplicações sem servidor em Wasm. Eles abstraem os detalhes do tempo de execução WASI e fornecem padrões familiares — manipuladores HTTP, armazenamento chave-valor, tarefas agendadas — executando tudo por Wasm. A promessa é escrever a lógica de negócio uma única vez, em qualquer linguagem que compile para Wasm, e implantá-la sem alterações em qualquer plataforma compatível com WASI.

A melhor forma de começar depende do objetivo. Para usar Wasm no navegador, o caminho mais rápido é Rust com wasm-pack. Instale o Rust, adicione o alvo wasm32-unknown-unknown e crie um projeto com wasm-pack new. O projeto gerado inclui um exemplo funcional com uma função Wasm chamável do JavaScript, um script de construção que produz um pacote compatível com npm e um arcabouço de testes que executa seu módulo num navegador sem interface.

Para explorar Wasm no servidor, comece pelo Wasmtime e sua ferramenta de linha de comando. Instale o wasmtime, compile qualquer programa C ou Rust com suporte a WASI e execute-o com wasmtime programa.wasm. Você verá que um programa de linha de comando compilado para Wasm se comporta como um binário nativo: lê da entrada padrão, escreve na saída padrão, acessa arquivos e termina com um código de estado. A experiência é surpreendentemente fluida.

Para experimentar na borda e em serverless, o Cloudflare Workers oferece um plano gratuito com suporte a Wasm. Escreva uma função em Rust, compile-a para Wasm e implante-a na rede global da Cloudflare. Você verá tempos de resposta abaixo de 10 milissegundos na maioria das localidades e comprovará em primeira mão como o Wasm elimina a partida a frio como preocupação.

O primeiro passo mais prático com Wasm não é reescrever toda a aplicação. Encontre uma função computacionalmente cara — um filtro, uma transformação, uma validação —, reescreva-a em Rust, compile-a para Wasm e integre-a à base de código existente. Meça a diferença. Quando vir um ganho de três vezes com cinquenta linhas de Wasm, entenderá por que essa tecnologia importa.

O cenário de ferramentas melhora depressa. wasm-pack, cargo-generate e wasm-tools oferecem um fluxo de desenvolvimento maduro. A cadeia Binaryen traz o wasm-opt para otimizar módulos e reduzir seu tamanho em 20 a 30 por cento. Wasmtime e Wasmer seguem fechando a distância para a execução nativa. E o modelo de componentes logo tornará os módulos interoperáveis de maneiras impossíveis quando o Wasm surgiu.

O WebAssembly não substitui a web como a conhecemos: enriquece a plataforma, com um segundo tempo de execução que faz o que o JavaScript não pode. Da próxima vez que enfrentar um problema de desempenho em que pareça estar brigando com a natureza dinâmica do JavaScript, considere se a parte pesada em cálculo poderia ser extraída para um módulo Wasm. As ferramentas estão prontas para produção, o ganho é real, e o futuro do Wasm — com o modelo de componentes, a WASI preview 2 e suporte mais amplo a linguagens — só melhora.

A plataforma web foi projetada para ser extensível. O WebAssembly é a sua extensão mais importante em uma década. Entendê-lo não é opcional para quem quer construir aplicações que empurram os limites do que a web consegue fazer.