WebAssembly e WASI: como executar aplicações portáteis

O que é WebAssembly?

WebAssembly é um formato de instruções binárias projetado como alvo de compilação portátil.

Em vez de distribuir o código-fonte original, uma ferramenta compila partes do programa para um módulo .wasm. Um motor valida esse módulo e executa suas instruções em uma máquina virtual controlada.

A documentação oficial do WebAssembly descreve um ambiente de execução eficiente, seguro em memória e isolado. “Isolado”, porém, não significa que todo módulo seja confiável.

Significa que o código não recebe acesso direto e irrestrito à máquina: ele interage com o exterior por importações fornecidas pelo ambiente que o hospeda.

Uma analogia útil é pensar no Wasm como uma peça de máquina com conectores bem definidos.

A peça contém a lógica de cálculo, mas não decide sozinha onde ler um arquivo, como abrir uma conexão ou em qual janela desenhar.

O navegador ou runtime disponibiliza os conectores permitidos.

O nome pode confundir quem conhece linguagem Assembly. WebAssembly não é o assembly específico de um processador físico.

É uma representação virtual, estruturada e independente da arquitetura de CPU, que o motor transforma em código adequado ao dispositivo.

O que WebAssembly não é

Wasm não é um sistema operacional, uma linguagem de uso geral para escrever aplicações do zero nem uma embalagem que torna qualquer programa automaticamente portátil.

Ele também não é uma forma de executar um binário Linux comum em todo lugar.

• Não inclui APIs do ambiente por padrão: arquivos, rede, relógio e interface gráfica dependem do host.
• Não elimina diferenças de plataforma: bibliotecas nativas, chamadas de sistema e extensões específicas ainda podem impedir uma compilação portátil.
• Não substitui todo o ecossistema web: no navegador, JavaScript continua sendo a ponte mais comum para DOM e APIs Web.
• Não garante desempenho superior: o resultado depende do tipo de tarefa, da integração e do custo de mover dados entre fronteiras.

Como Wasm funciona no navegador

No navegador, o módulo roda dentro da sandbox e obedece às políticas de segurança da Web.

Uma página pode carregar o binário, fornecer funções importadas e chamar funções exportadas pelo módulo. Um exemplo mínimo em JavaScript seria:

const { instance } = await WebAssembly.instantiateStreaming(
  fetch("/soma.wasm")
);

const resultado = instance.exports.somar(2, 3);
console.log(resultado);

O exemplo pressupõe que soma.wasm exporte a função somar. Em aplicações reais, pode ser necessário fornecer memória, funções do host e uma camada de conversão de tipos.

Strings, objetos complexos e estruturas da linguagem de origem não atravessam a fronteira tão diretamente quanto números simples.

Wasm costuma fazer sentido no front-end quando existe trabalho computacional intenso: codificação de áudio e vídeo, edição de imagem, simulação, CAD, jogos, compressão ou reaproveitamento de uma biblioteca madura escrita em outra linguagem.

Para manipular botões, formulários e o DOM, JavaScript assíncrono e as APIs nativas do navegador normalmente oferecem um caminho mais direto.

O que é WASI?

WASI é a sigla de WebAssembly System Interface. Segundo a introdução oficial do WASI, trata-se de um conjunto de especificações de APIs em processo de padronização para software compilado para WebAssembly.

Seu objetivo é oferecer interfaces seguras e portáteis que não pressuponham um sistema operacional específico.

Fora do navegador, um runtime como o Wasmtime pode hospedar o componente e implementar essas interfaces.

O programa pede uma operação por meio do contrato WASI; o host decide se concede o recurso e como traduz a operação para a plataforma real.

Por isso, chamar WASI de “POSIX para WebAssembly” ajuda apenas como primeira aproximação. As versões atuais não procuram copiar cada chamada de um Unix.

Elas organizam capacidades em interfaces menores e compostas, adequadas a ambientes que vão de servidores a edge e dispositivos embarcados.

Como Wasm, WASI e Component Model se relacionam

Camada	Responsabilidade	Exemplo
WebAssembly Core	Instruções, memória, funções, validação e execução do módulo	Uma rotina de compressão compilada para .wasm
Component Model	Interfaces tipadas, empacotamento e composição entre componentes	Um componente exporta um processador de imagens
WASI	Interfaces padronizadas para capacidades do sistema e serviços	Acesso autorizado a arquivos, relógio ou HTTP
Runtime ou host	Executa, fornece implementações e aplica permissões	Um runtime concede somente uma pasta específica

O módulo Core resolve cálculos de baixo nível. O Component Model cria uma camada mais expressiva para descrever o que uma unidade oferece e exige.

WASI fornece conjuntos de interfaces reutilizáveis. O runtime conecta tudo ao ambiente real.

Essa separação permite, por exemplo, que uma aplicação hospedada em Node.js no back-end carregue uma biblioteca Wasm para uma tarefa específica, ou que um runtime dedicado execute um componente sem depender de Node.js.

A arquitetura concreta muda; os contratos tornam a integração explícita.

O que mudou no WASI 0.3

O WASI 0.3.0 foi lançado em 11 de junho de 2026 como uma versão estável da especificação.

A principal mudança foi levar operações assíncronas para o próprio Component Model, com três primitivas: funções assíncronas, fluxos tipados e futuros.

A página oficial do WASI 0.3 explica que isso resolve dificuldades de compor operações assíncronas através de várias fronteiras de componentes.

• async func permite declarar uma função assíncrona no contrato.
• stream<T> representa uma sequência assíncrona e tipada de valores.
• future<T> representa um resultado que será concluído posteriormente.

“Estável” se refere à especificação 0.3.0 e às garantias de compatibilidade dessa linha. Não significa que todas as linguagens, geradores de bindings e runtimes já tenham o mesmo nível de suporte.

Durante a adoção, versões de ferramentas e pacotes WIT precisam ser compatíveis entre si. Em produção, confirme a matriz do runtime escolhido e fixe versões no projeto.

WIT e interfaces tipadas

WIT, ou Wasm Interface Type, é a linguagem de definição de interfaces do Component Model. Ela descreve contratos, não a lógica interna.

A referência oficial de WIT organiza esses contratos em interfaces, mundos, tipos e funções.

package exemplo:imagem;

interface filtro {
  processar: func(entrada: list<u8>) -> list<u8>;
}

world plugin {
  export filtro;
}

Nesse contrato, o componente exporta uma interface chamada filtro. Ela recebe e devolve listas de bytes.

Ferramentas geram adaptações para os tipos de cada linguagem, reduzindo a necessidade de acordos manuais sobre layout de memória.

A ideia ganha valor quando equipes desejam combinar uma biblioteca de alto desempenho em Rust para programação de sistemas com componentes escritos em outras linguagens.

Cada unidade conhece o contrato, não a implementação interna de todas as demais.

WebAssembly vs. containers

Containers e componentes Wasm atacam problemas relacionados à distribuição, mas em níveis diferentes.

Um container normalmente empacota aplicação, bibliotecas e parte do ambiente de usuário de um sistema operacional.

Um componente Wasm empacota código para uma máquina virtual e declara as interfaces de que precisa.

Critério	Container	WebAssembly/WASI
Unidade distribuída	Imagem com aplicação e dependências	Módulo ou componente Wasm
Dependência do host	Kernel compatível e runtime de containers	Runtime Wasm e interfaces suportadas
Integração com o sistema	Ampla, conforme namespaces e permissões	Somente capacidades e interfaces concedidas
Compatibilidade de software existente	Alta para aplicações do sistema-alvo	Depende da linguagem e das bibliotecas
Melhor encaixe	Serviços completos e ecossistemas existentes	Plugins, funções, bibliotecas e workloads isolados

Wasm pode ter artefatos menores e inicialização rápida em determinados runtimes, mas isso não transforma toda aplicação em candidata.

Containers têm compatibilidade operacional madura e aceitam software que espera um ambiente Linux convencional.

Se a distinção entre imagem, processo e virtualização ainda estiver nebulosa, consulte o comparativo entre Docker e máquinas virtuais.

Casos de uso com bom potencial

• Plugins e extensões: terceiros entregam lógica em um formato isolado e o host expõe uma API limitada.
• Edge e funções sob demanda: workloads pequenos podem se beneficiar de inicialização rápida e isolamento por instância, dependendo da plataforma.
• Bibliotecas multiplataforma: um algoritmo de compressão, parser, codec ou motor de regras pode ser reutilizado em vários hosts.
• Processamento no navegador: tarefas intensivas podem rodar perto do usuário, reduzindo viagens ao servidor.
• Execução de código não confiável: uma sandbox com capacidades mínimas oferece uma fronteira adicional, desde que o runtime seja atualizado e a política seja restritiva.
• Composição entre linguagens: componentes com interfaces WIT permitem integrar implementações sem expor detalhes internos.

Em uma arquitetura de microsserviços, Wasm pode aparecer dentro de um serviço, em uma plataforma de plugins ou no edge.

Ele não elimina os desafios distribuídos de rede, consistência, observabilidade e propriedade de dados.

Quando WebAssembly e WASI não são a melhor escolha

Evite adotar a tecnologia apenas por curiosidade arquitetural quando a aplicação já funciona bem em seu runtime nativo.

Um CRUD comum, um painel administrativo ou um serviço simples raramente ganha algo ao adicionar compilação, bindings, runtime e depuração em outra camada.

• A biblioteca depende fortemente de APIs do sistema operacional que não têm interface equivalente.
• A equipe precisa de ferramentas de depuração e perfilamento que ainda não atendem ao fluxo escolhido.
• A comunicação com o host domina o tempo de execução, anulando o benefício do processamento interno.
• O produto exige integração nativa profunda com drivers, janelas ou dispositivos específicos.
• Uma biblioteca normal ou um processo isolado resolve o problema com menor custo operacional.

Segurança baseada em capacidades

O modelo do WASI parte do princípio de autoridade não ambiente: um componente começa sem acesso ao mundo externo e recebe apenas o que o host concede.

A documentação de segurança do WASI destaca que essa decisão é aplicada na fronteira do runtime.

Na prática, um processador de imagens pode receber acesso de leitura a um diretório de entrada e escrita a outro, sem enxergar o restante do disco.

Uma extensão pode receber uma interface abstrata de armazenamento, em vez de credenciais diretas do banco.

A vantagem desaparece se o host conceder permissões amplas. A sandbox também não substitui atualização do runtime, validação de entrada, limites de CPU e memória, observabilidade, isolamento de segredos e revisão das interfaces importadas.

Segurança é o conjunto dessas decisões, não uma propriedade mágica do arquivo .wasm.

Desempenho: meça o sistema completo

WebAssembly foi desenhado para decodificação e execução eficientes, mas comparar apenas uma função pode esconder o custo total.

Avalie tempo de inicialização, compilação ou cache do módulo, tamanho do download, consumo de memória e frequência de chamadas ao host.

Uma rotina longa, com muitos cálculos sobre um bloco grande de dados, tende a amortizar a travessia da fronteira. Milhares de chamadas pequenas podem gerar o efeito oposto.

No navegador, copiar dados entre JavaScript e a memória linear do módulo também pode se tornar relevante.

Faça benchmarks com entrada real, em máquinas representativas e incluindo carregamento, conversão, I/O e telemetria.

Compare com a solução atual. “Perto do nativo” é uma possibilidade para certos workloads, não um resultado automático de qualquer compilação.

Os limites da portabilidade

A frase “compile uma vez, execute em qualquer lugar” só é verdadeira quando todos os lugares implementam o conjunto de recursos usado pelo artefato. A portabilidade depende de pelo menos cinco compatibilidades:

1. o alvo de compilação e a versão da linguagem;
2. os recursos de WebAssembly exigidos pelo binário;
3. a versão do Component Model e dos pacotes WIT;
4. as interfaces WASI implementadas pelo runtime;
5. as capacidades que o host realmente concede na implantação.

Também há diferenças entre um módulo Core, um componente WASI 0.2 e um componente WASI 0.3. O mesmo sufixo .wasm não garante que dois artefatos tenham o mesmo modelo de execução.

Registre o alvo, fixe a cadeia de ferramentas e teste no runtime final.

Como avaliar a adoção na prática

Comece por um componente pequeno, com fronteira clara e uma métrica verificável.

Um parser, filtro, validador ou motor de regras costuma ser mais apropriado para um experimento do que migrar um serviço inteiro.

1. Defina o problema: portabilidade, isolamento, composição entre linguagens ou desempenho?
2. Mapeie dependências: identifique arquivos, rede, relógio, aleatoriedade e bibliotecas nativas.
3. Escolha o formato: módulo Core, componente e versão de WASI compatível com o runtime.
4. Modele a interface: mantenha poucos dados e chamadas atravessando a fronteira.
5. Restrinja capacidades: conceda somente os recursos necessários.
6. Meça: compare latência, throughput, memória, tamanho, inicialização e esforço operacional.
7. Teste portabilidade: execute o mesmo artefato nos ambientes que realmente serão suportados.

O experimento deve responder a uma hipótese. Se o benefício não aparecer, manter a solução nativa é uma decisão técnica válida.

Se aparecer, o próximo passo é automatizar a matriz de compilação e execução no CI, além de documentar versões, permissões e limites.

Perguntas frequentes

WebAssembly é uma linguagem de programação?

Não no sentido usual. WebAssembly é um formato de instruções e alvo de compilação. Desenvolvedores normalmente escrevem em Rust, C, C++, Go, C# ou outra linguagem compatível e usam uma cadeia de ferramentas para produzir o artefato Wasm.

WASI funciona no navegador?

Pode funcionar quando uma camada no navegador implementa ou adapta as interfaces necessárias, mas WASI é especialmente relevante para ambientes fora da Web. Não presuma que toda interface de arquivos, sockets ou processos exista nativamente em qualquer navegador.

WebAssembly substitui JavaScript?

Não de forma geral. No front-end, Wasm complementa JavaScript em tarefas específicas. JavaScript continua oferecendo integração direta com DOM, eventos e APIs Web, enquanto Wasm é forte como unidade de processamento ou como forma de reutilizar bibliotecas.

WebAssembly substitui Docker?

Não como regra. Containers são adequados para empacotar serviços e dependências com ampla compatibilidade de sistema. Wasm oferece uma unidade menor e uma fronteira de capacidades, mas exige que a aplicação e suas dependências sejam compatíveis com o alvo e o runtime.

Quais linguagens compilam para WebAssembly?

Rust, C e C++ têm ecossistemas conhecidos, e outras linguagens também oferecem suporte em diferentes níveis. A pergunta decisiva não é apenas se a linguagem gera Wasm, mas se suas bibliotecas, runtime e ferramentas suportam o Component Model e a versão de WASI necessária.

WASI está pronto para produção?

Há versões estáveis e usos de produção, mas o suporte varia por versão. WASI 0.1 tem adoção ampla; WASI 0.2 estabeleceu a base do Component Model; WASI 0.3 estabilizou o modelo assíncrono em 2026, enquanto o suporte de toolchains e runtimes continua avançando.

Valide o caso e fixe a matriz usada.

Conclusão

WebAssembly fornece uma unidade de execução portátil e isolada. WASI oferece interfaces padronizadas para capacidades do ambiente.

O Component Model adiciona contratos tipados e composição. Juntos, eles tornam plugins, bibliotecas multiplataforma, edge e integração entre linguagens possibilidades concretas.

O melhor resultado aparece quando o componente tem uma fronteira clara, poucas dependências do sistema e um benefício mensurável.

Antes de migrar uma aplicação inteira, escolha uma rotina pequena, modele os imports e exports, conceda o mínimo de capacidades e teste o artefato em todos os runtimes que pretende suportar.

Portabilidade é uma propriedade verificada na prática, não apenas uma promessa do formato.