O WebAssembly foi lançado com uma proposta clara: performance quase nativa para código rodando dentro do navegador, pra que computação pesada não precisasse ser um compromisso no formato JavaScript. Essa proposta era verdadeira, e ficou quase à margem de onde o Wasm acabou realmente importando mais.
A parte que ninguém estava vendendo
Fora do navegador, o Wasm acabou resolvendo um problema que não tinha nada a ver com navegadores: rodar código não confiável de forma segura e portátil, sem precisar empacotar um container inteiro pra isso. Um módulo Wasm é isolado (sandboxed) por padrão, inicia em milissegundos em vez dos segundos que uma imagem de container leva pra dar cold-start, e roda de forma idêntica independente do sistema operacional ou arquitetura de CPU por baixo.
Essa combinação é exatamente o que alguns problemas pouco glamorosos, mas bem reais, precisavam:
- Sistemas de plugins. Em vez de carregar código nativo arbitrário (um pesadelo de segurança) ou chamar um subprocesso via shell (lento, pesado), uma aplicação consegue rodar módulos Wasm enviados por usuários com uma barreira de sandbox real e limites de recurso previsíveis.
- Edge compute. Provedores rodando funções em centenas de localidades se importam muito com o tempo de cold-start. Um módulo Wasm iniciando em milissegundos de um dígito muda o que é viável rodar na edge comparado a um container que leva um segundo ou mais pra subir.
- Extensibilidade poliglota. Um módulo Wasm pode ser compilado a partir de Rust, C, Go ou uma dezena de outras linguagens, e o host não precisa saber qual. Esse é um problema genuinamente difícil de resolver de qualquer outra forma sem escolher uma única linguagem de script embutida e conviver com as limitações dela.
Por que isso passou despercebido
Nada disso era o recurso principal quando o Wasm foi lançado. Ele foi apresentado como "código rápido no navegador", e por alguns anos foi o único lugar onde as pessoas procuravam por ele. A história do lado servidor precisou que o WASI (a WebAssembly System Interface) amadurecesse o suficiente pra dar aos módulos Wasm uma forma padrão de conversar com arquivos, rede e o mundo externo — sem isso, um módulo isolado sem nenhuma história de I/O é um brinquedo interessante, não infraestrutura.
Onde isso realmente importa
Se você está avaliando Wasm hoje, o caso de uso no navegador ainda é real, mas mais restrito do que a proposta original sugeria — a maioria dos apps não tem um gargalo de computação que justifique a complexidade. Os casos de uso no servidor e na edge são onde as propriedades de isolamento e tempo de inicialização resolvem problemas que antes eram caros de resolver bem. É um caso raro de uma tecnologia cujo segundo caso de uso acabou sendo mais relevante do que aquele para o qual ela foi originalmente construída.
Vamos conversar?
Tem um projeto, uma vaga ou só quer trocar uma ideia sobre o assunto? Envie uma mensagem.
Entrar em contato