WASI 0.2.0 e Por que Isso Importa

Artigo original ↗ Discussão no Hacker News ↗

O novo lançamento WASI Preview 2 do WebAssembly é visto como um grande passo para tornar o Wasm um runtime prático e portátil além do navegador, graças à sua interface de sistema baseada em capacidades e ao modelo de componentes/Canonical ABI emergente para interoperabilidade poliglota. Comentadores debatem se essa abordagem é um “segundo sistema” excessivamente complicada ou uma base necessária para workloads seguros no estilo serverless e sistemas de plugins, contrastando-a com esforços mais antigos como JVM/CLR, applets Java e NaCl. Há entusiasmo em torno de usos reais (de Figma a extensões do VS Code) e potencial futuro (APIs de GUI, async e GC no Preview 3), junto com frustração por peças ausentes como gráficos padronizados, threading e ferramentas suaves para linguagens como C.

APIs de Gráficos e GUI

  • Vários comentadores querem uma API padrão de GUI no estilo framebuffer para WASI, para que apps WASM possam desenhar em uma tela fora dos navegadores.
  • Outros argumentam que framebuffers estão ultrapassados e que APIs de nível mais alto, como WebGPU, são melhores; o contraponto é que o WebGPU ainda não é ubíquo e o WASM roda além dos navegadores.
  • Contribuidores envolvidos com o WASI dizem que os gráficos não foram bloqueados por fornecedores; simplesmente ainda não tiveram foco dos contribuidores, que tem sido principalmente em serverless e peças fundamentais.
  • Há interesse em futuras propostas de GUI/dispositivos de E/S, mas ainda não existe um padrão concreto.

Modelo de Componentes, Preview 2 e Compatibilidade

  • O WASI Preview 2 é construído sobre o WebAssembly Component Model, separando o “core WASM” de APIs de nível mais alto.
  • Módulos WASI existentes não são diretamente compatíveis; adaptadores são necessários, o que alguns veem como confuso e um “efeito de segundo sistema”.
  • Outros argumentam que o modelo de componentes trata de interoperabilidade limpa e de uma ABI canônica (sem exports de memória compartilhada, recursos baseados em handles) que permite que diferentes linguagens e modelos de memória cooperem.
  • O modelo de componentes pode ser usado sem o WASI e está em um caminho de padronização, embora ainda não esteja totalmente formalizado.

Que Problema o WASI Resolve

  • Várias explicações: o core WASM sozinho não consegue fazer E/S; o WASI define um sistema de interface baseado em capacidades (arquivos, rede etc.), especialmente para runtimes fora do navegador.
  • Ele é comparado a “POSIX para WASM”, embora alguns observem que o WASIX mira de forma mais direta na semântica POSIX.
  • Segurança baseada em capacidades (permissões mínimas e explícitas) é destacada como um objetivo central de design.

Casos de Uso vs. Ceticismo

  • Céticos dizem que, após cerca de 10 anos de trabalho relacionado a WASM, veem בעיקר demos, ferramentas complexas e valor econômico pouco claro, especialmente em comparação com builds nativos.
  • Outros citam usos práticos: apps no navegador (ferramentas de design, jogos, vídeo, emulação de Flash), sistemas embarcados, plugins poliglotas, extensões do VS Code e scripting de mods de jogos.
  • O WASM no lado do servidor é visto como promissor, mas ainda imaturo; desempenho e suporte de provedores de nuvem continuam em aberto.

Comparações com JVM/CLR e Applets

  • Alguns veem o WASI como a recriação de ideias do CLR, da JVM e de esforços anteriores de bytecode; o debate gira em torno de se “recriar” é ruim caso esta versão obtenha adoção real e seja mais aberta.
  • Applets vs WASM: comentadores destacam a superfície exposta menor do WASM, melhor tempo de inicialização, foco em múltiplas linguagens e apoio de uma coalizão de fornecedores.

Poliglota, FFI e Recursos Futuros

  • Há forte interesse em FFI poliglota mais fácil; o Preview 2, junto com o modelo de componentes e a ABI canônica, é visto como base para isso.
  • Ferramentas e frameworks (por exemplo, sistemas de plugins) estão surgindo, mas ainda são limitados em tipos de dados e ergonomia.
  • Adições futuras como GC e async (Preview 3) são aguardadas para tornar o WASM um melhor runtime para linguagens como JavaScript e Dart, e para melhorar a integração com motores JS compilados para WASM.