- WebAssembly (Wasm) continua sendo usado como tecnologia central em diversos produtos reais e desempenha um papel importante em motores de jogo, ferramentas de design e contêineres web
- A linguagem em si tem uma estrutura que mapeia com eficiência para o hardware moderno e foi projetada com foco em segurança e portabilidade
- Seu modelo de segurança adota a abordagem deny-by-default, permitindo isolamento em nível de processo e execução rápida
- É utilizado em vários ambientes por meio de um ecossistema de plugins e suporte entre linguagens, mas ainda não houve adoção em nível de substituir toda a web no navegador
- Atualmente, o WebAssembly está profundamente integrado no nível de bibliotecas e runtimes, e sua padronização e expansão de recursos avançam rapidamente
Casos de uso reais
- O WebAssembly é responsável por funções centrais em Godot, Figma, Stackblitz, Squoosh.app, Zellij e Ruffle
- O Godot o usa para builds de jogos para a web, e o Figma para converter código C++ em uma forma executável no navegador
- O Stackblitz utiliza Wasm em seus contêineres web, e o Ruffle como emulador de Flash
- No entanto, sites de grande porte construídos inteiramente sobre Wasm ainda são raros; na maioria dos casos, ele é usado apenas em funcionalidades específicas
Definição e velocidade do WebAssembly
- WebAssembly é uma linguagem, e seu desempenho não é uma característica própria da linguagem, mas depende do motor de execução
- Assim como no JavaScript, o runtime engine (V8, SpiderMonkey etc.) determina a velocidade de execução
- O WebAssembly tem uma estrutura que mapeia eficientemente para o hardware moderno, podendo ser tanto compilado quanto interpretado
Estrutura de mapeamento eficiente
- O Wasm é um bytecode próximo de linguagem assembly, que pode ser compilado para a maioria dos hardwares sem perdas
- WAT (WebAssembly Text) é a representação textual do Wasm, com conversão quase 1:1
- É semelhante ao bytecode da JVM, mas com uma API pequena e fortes garantias de segurança
- O acesso à memória é explícito, e apenas recursos permitidos pelo ambiente hospedeiro podem ser usados
Wasm como alvo de compilação
- Diversas linguagens como Rust, C, Zig, Go, Kotlin, Java e C# podem ser compiladas para Wasm
- Linguagens interpretadas como Python, PHP e Ruby também podem ser executadas em builds Wasm
- Navegadores incluem um engine Wasm por padrão, e também existem runtimes independentes como Wasmtime, WasmEdge e Wasmer
- Um único artefato Wasm pode ser executado de forma independente de hardware
Estrutura de segurança e usos
- O WebAssembly adota um modelo de segurança deny-by-default, em que acessos externos só são permitidos por imports explícitos
- Com pilha de fluxo de controle oculta, memória linear e conjunto de instruções limitado, ele garante forte isolamento
- A Cloudflare isola a execução de código baseado em Wasm usando isolates do V8, e a Fermyon oferece tempo de inicialização em nível de submilissegundos
- O Ruffle restaura conteúdo Flash com segurança, o Pyodide executa Python em Wasm, e o Figma executa plugins com QuickJS baseado em Wasm
Portabilidade e embedding
- Runtimes Wasm são leves, e Zellij, Envoy e Lapce adotaram Wasm em seus sistemas de plugins
- Mesmo em ambientes com engine JavaScript, é possível usar diversas bibliotecas Wasm para processamento de imagem, OCR, motores de física, renderização, toolkits de mídia, bancos de dados e parsers
- Na maioria dos casos, o usuário nem percebe que Wasm está sendo usado, pois tudo funciona de forma transparente dentro da biblioteca
Revisão de velocidade e tamanho
- Os navegadores executam Wasm pelo mesmo pipeline do JS, então existem limites de desempenho impostos pela arquitetura do engine
- A eficiência varia de acordo com o sistema de tipos da linguagem e o nível de otimização do compilador
- O custo da fronteira entre host e programa e o aumento do tamanho do binário são apontados como desvantagens
- O padrão WASI tenta aliviar isso, mas a padronização do tipo string ainda não está concluída
- O Zig gera os menores binários Wasm
- Em ambientes nativos, pode haver queda de desempenho por causa de threading, IO e uso de memória
Tendências no desenvolvimento da linguagem e dos padrões
- A padronização do Wasm avança em paralelo pelo grupo de trabalho do W3C e pela Bytecode Alliance
- Esta última lidera o desenvolvimento focado em ferramentas como WIT e Component Model
- Novas propostas de recursos estão sendo adotadas rapidamente, embora haja debates sobre a velocidade e a direção desse processo
- O Wasm está se expandindo menos como substituto do JavaScript e mais como tecnologia de integração interna
- Frameworks como Blazor e Leptos usam Wasm sem lidar diretamente com JS
- Hoje, o Wasm é adotado principalmente por criadores de bibliotecas, e desenvolvedores comuns podem usá-lo sem precisar conhecer seu funcionamento interno
- A dificuldade dos materiais educacionais é apontada como barreira de aprendizado, e projetos de estudo como
watlings são apresentados
1 comentários
Comentários do Hacker News
Acho que o Wasm cumpriu a maior parte dos objetivos que tinha quando foi criado
Pessoalmente, usei Wasm como componente central em dezenas de projetos
Os motores JS são muito rápidos, mas o Wasm ainda oferece um nível maior de controle sobre a CPU e desempenho excelente
Só não correspondeu à expectativa de substituir completamente JS+HTML+CSS. Acho que a falta de bindings para o DOM é uma grande razão para isso
Também usei frameworks Wasm como o Yew, mas pareciam uma camada estranha colocada por cima do JS
Ainda não usei Blazor, mas continuo achando mais confortável escrever em JS
Mesmo assim, o Wasm roda silenciosamente em muitos lugares, e acho que isso é a verdadeira prova de sucesso
Por exemplo, a função de ajustar a velocidade do áudio no navegador só atinge esse nível de desempenho porque roda uma biblioteca C++ em Wasm
Se surgirem bindings decentes para o DOM, o JS será empurrado para fora do frontend em menos de 10 anos
Com C#, é fácil compartilhar código entre backend e frontend, e os templates Razor também têm bom suporte nas IDEs
Mas o bundle fica grande porque é preciso levar o .NET CLR e a BCL inteiros
Como o acesso ao DOM é difícil, o Blazor usa uma arquitetura com um pequeno renderizador de Virtual DOM no lado do JS
O desempenho é aceitável, mas ainda é mais lento do que JS escrito à mão
O Bolero baseado em F# também é interessante, mas é difícil convencer a equipe
Para interagir com o DOM, é preciso uma linguagem de alto nível adequada para isso
O JS cumpre bem esse papel, e a combinação HTML/CSS/JS já virou a linguagem comum do desenvolvimento de UI
Existem tentativas de abandonar o rendering do navegador e ir para uma abordagem baseada em canvas, mas isso ainda é um nicho
Seria horrível viver num mundo em que até sites simples precisassem baixar runtimes de vários MB
A causa real da lentidão não é o JS, mas o DOM. No fim, é preciso interagir com o DOM de qualquer forma
Trabalhei com WebAssembly por alguns anos e em breve vou lançar um framework baseado em Wasm
O ecossistema evoluía rapidamente e de repente desacelerou, enquanto a introdução de WASI e do Component Model gerou confusão
Como o nível de suporte varia entre os engines, muitas vezes é preciso ficar pulando entre documentação, código e issues
O maior problema é o suporte a JS/TS. Hoje a forma de integração é quase um hack, então não é estável
Web Containers trouxeram melhorias, mas muitos desenvolvedores já migraram para Bun
O potencial do Wasm é enorme
Em teoria, ele pode se tornar um alvo de compilação comum para todas as plataformas
Mas na prática é meio decepcionante se resumir a tornar algumas funções do Figma mais rápidas
A estrutura de desenvolvimento centrada em comitês também é um limite, porque torna tudo lento
Na época do Native Client, já era possível ter apps em velocidade nativa, mas hoje o Wasm é mais lento do que isso
Poderiam ter aplicado ao Wasm a mesma estrutura de bindings de JS, o que é uma pena
Além disso, o Wasm nem é mais rápido que JS
HTML/CSS/JS já provaram sua utilidade, enquanto o Wasm ainda é uma stack tecnológica estranha para muita gente
O ecossistema centrado em Docker está atrapalhando
Muitas ferramentas de build do ecossistema JS são escritas em Rust, e algumas rodam no navegador via Wasm
O ecossistema React e npm também usa Wasm internamente
Se o Wasm desaparecesse, o mundo do frontend em JS seria bastante abalado
Mas frameworks de UI nativos em Wasm ainda são insuficientes
É ineficiente ter que depender de DOM e CSS e acessar as APIs do navegador via JS
Dá para controlar o DOM com Rust ou Kotlin, mas Rust é baixo nível demais para frontend
A compilação cruzada para mobile está aumentando cada vez mais, e o JetBrains Compose Multiplatform é um exemplo disso
O que atrapalha o avanço do Wasm é o tooling
O debugging ainda está em nível de
printf, e o plugin DWARF do Chrome não recebe updates há muito tempoO processo de gerar arquivos .wasm em cada linguagem e configurar import/export é complexo
O suporte a GC também não é completo, então ecossistemas como o .NET precisam levar seu próprio GC
O WIT parece mais uma nova tentativa de COM/CORBA/gRPC
O Emscripten é complexo e instável, e o wasi-sdk tem poucos recursos
Tanto o LLVM quanto os engines ainda têm otimização insuficiente, e o tooling Wasm do Rust está praticamente parado
Nem sequer existe um jeito padronizado de importar módulos Wasm em JS
O suporte a multithreading também exige headers COOP/COEP, então isso não funciona no GitHub Pages
Se o tooling tivesse ido além do nível de “demo técnica”, ele seria muito mais usado
Nossa empresa, Leaning Technologies, usa Wasm ativamente
Com o WebVM, executamos binários x86 no navegador,
com o BrowserCraft, rodamos apps Java (incluindo Minecraft),
e com o BrowserPod, executamos contêineres Node.js no navegador
É extremamente poderoso, mas é uma ferramenta para usuários avançados. Compilar lógica comum de frontend para Wasm é ineficiente
Comentaram que a velocidade de evolução do CheerpJ é impressionante, e que, se tivesse surgido 10 anos antes, talvez a plataforma web fosse diferente
Para quem não gosta de JS, o verdadeiro atrativo do Wasm é criar sites sem JS
Trabalho no framework Wasm baseado em Rust chamado Dioxus
No frontend com Wasm, o problema era a falta de ferramentas básicas, como code splitting, hot reload, símbolos de debug e integração de assets
Em 2025, muita coisa melhorou, e a integração com ferramentas como o Vite também ficou melhor
Graças às ferramentas de IA, a velocidade de desenvolvimento em Rust também aumentou, e espero que os frameworks Wasm recebam mais atenção daqui para frente
Houve críticas ao tamanho do binário do Wasm, dizendo que ele é grande demais
Em ambientes DSL, o download pode levar de vários segundos a vários minutos
A alegação é que JS é menor e ainda pode ser executado durante o download
Em builds com Rust, pode cair para algo entre 10 e 100 KB
JS não é executado durante o download, e o Wasm pode iniciar mais rápido graças à compilação em streaming
Isso acaba duplicando funcionalidades que o navegador já oferece
Por exemplo, o FSHistory implementa emulação x86 em 24 KB
Só que o ecossistema nativo não está acostumado a otimizar tamanho de código
A frase do artigo de que “não existe nenhum grande site feito em Wasm” não bate com a minha experiência
O objetivo dos projetos em Wasm nunca foi substituir o webapp inteiro
Parece que as pessoas criaram expectativas erradas e ficam perguntando “por que isso não aconteceu?”
Eu realmente apliquei Wasm em vários casos de uso reais
Dá para tratar isso no backend, enviando só as partes necessárias