Perdendo o ponto do WebAssembly

Artigo original ↗ Discussão no Hacker News ↗

O papel do WebAssembly na pilha da web é contestado: alguns o veem principalmente como uma forma de construir aplicativos de navegador em linguagens que não sejam JavaScript, enquanto outros argumentam que sua verdadeira promessa está em ser um bytecode de baixo nível, em sandbox, para plugins, edge computing e binários multiplataforma além do navegador. Comentadores debatem suas limitações no navegador hoje — especialmente a necessidade de passar pelo JavaScript para acesso ao DOM, a complexidade das ferramentas e os runtimes grandes — junto com recursos emergentes como Wasm GC e o modelo de componentes, que visam melhorar interoperabilidade e desempenho. Também existe tensão entre o poder e a segurança de módulos opacos e compilados e a perda da transparência de “view source” que historicamente tornava a web fácil de aprender e de hackear.

Para que o WebAssembly é “para”

  • Um grupo argumenta que o principal ganho hoje é escrever aplicativos web em linguagens que não sejam JavaScript/TypeScript.
  • Outros dizem que isso já era possível via compile-to-JS (asm.js, ClojureScript, GWT, etc.), então isso por si só é incremental.
  • A visão mais “empolgante” vê o WASM como uma camada geral, segura e portátil de computação/sandbox: plugins, edge compute, IoT, dependências nativas seguras, etc.

WASM vs JavaScript na Web

  • Muitos desenvolvedores querem que o WASM substitua o JS para poder usar suas linguagens preferidas tanto no cliente quanto no servidor.
  • Outros veem o JS como aceitável ou até poderoso, com problemas mais no ecossistema/ferramentas do que na linguagem central.
  • Um padrão prático recorrente: manter JS como “andaime” ou cola e descarregar os caminhos quentes ou bibliotecas pesadas para o WASM.

DOM, APIs do navegador e ferramentas

  • Nos navegadores, o WASM não pode usar diretamente o DOM ou a maioria das APIs da web; ele precisa chamar funções JS “do host” como shims.
  • Com reference types e Wasm GC, passar referências opacas do host (por exemplo, nós do DOM) fica mais fácil e eficiente, mas ainda requer cola.
  • Um modelo de componentes e o WebAssembly Interface Types (WIT) estão sendo desenvolvidos para padronizar uma interoperabilidade mais rica, mas o progresso é lento e complexo.
  • Alguns reclamam de toolchains pesadas, runtimes de linguagem grandes e da dificuldade de fazer coisas como code-splitting e otimização do tempo de inicialização.

Opacidade, View-Source e acessibilidade

  • Há uma preocupação forte de que o WASM torne a web opaca: binários compilados são mais difíceis de entender do que HTML/JS, enfraquecendo a cultura de “view source” e o aprendizado casual.
  • Outros contra-argumentam que JS minificado já é opaco e que ferramentas melhores poderiam expor a fonte do WASM de forma semelhante.
  • Aplicativos WASM centrados em canvas correm o risco de baixa acessibilidade (leitores de tela, seleção de texto, layout de texto internacional) a menos que esforço extra e bibliotecas sejam usados.

Comparações com outros bytecodes e novidade

  • Alguns dizem que o WASM é “apenas mais um bytecode”, como JVM/CLR, e não justifica o hype.
  • Outros destacam diferenças: mais baixo nível, agnóstico à linguagem, formalmente especificado com validação checada por máquina, sandboxing forte e capacidades ambientais mínimas.

Adoção, casos de uso e ceticismo

  • Exemplos citados: aplicativos web complexos (ferramentas de design, visualizadores tipo Earth, jogos em Unity, C#/Blazor) já usando WASM de forma eficaz.
  • Céticos argumentam que, após quase uma década, o WASM ainda não tem um “killer app” claro e dominante na web (sem DOM direto, threading estranho, muita cola) e questionam se uma camada universal de computação é necessária ou prudente.