Lançamento do Wasmer 5.0

Novo backend experimental

• Adicionado suporte a V8, Wasmi e WAMR
• Agora é possível integrar facilmente ao Wasmer qualquer interpretador ou runtime compatível com a especificação Wasm-C-API
• A integração com o V8 oferece uma excelente experiência de depuração por meio do depurador do V8 e do Chrome DevTools
• Usar o V8 como backend também significa suporte nativo a exceções do WebAssembly e coleta de lixo

Suporte a iOS (fornecido por meio de bindings para WAMR, Wasmi e V8)

• O Wasmer leva WebAssembly a dispositivos iOS por meio de um novo modo interpretador
• Aproveitando os recursos do V8, Wasmi e WebAssembly Micro Runtime (WAMR), os desenvolvedores agora podem executar módulos WebAssembly no iOS com fluidez
• Não são necessárias alterações na base de código, o que permite criar aplicações de alto desempenho no ecossistema Apple

Enxugamento da base de código

• Para o lançamento do Wasmer 5.0, o foco foi tornar a base de código do Wasmer o mais enxuta possível
• Algumas dependências usadas pelo Wasmer não eram mantidas havia muito tempo ou já estavam redundantes diante de crates mais novos e seguros
• Como os bindings do Emscripten quase não foram usados nos últimos 2 anos, o suporte foi descontinuado e, junto com a limpeza de dependências, isso removeu 20 mil linhas de código da base do Wasmer

Melhorias de desempenho

• A desserialização de módulos agora está até 50% mais rápida (ou seja, ao chamar Module::deserialize ou ao executar um módulo via wasmer run)
• Essas melhorias aproveitam uma atualização importante do rkyv, a biblioteca de desserialização zero-copy usada para desserializar módulos

Compiladores atualizados: Cranelift e LLVM 18

• Com a integração do Cranelift mais recente, a velocidade de execução em runtime melhorou significativamente, fazendo com que módulos WebAssembly rodem mais rápido do que nunca
• O Wasmer 5.0 agora inclui a versão mais recente do LLVM (18), dando aos desenvolvedores acesso às otimizações mais novas da toolchain
• A atualização do LLVM melhora compatibilidade e desempenho, oferecendo uma base robusta para compilar e executar módulos WebAssembly complexos
• O Wasmer 5.0 também traz suporte experimental a LoongAarch64
• No benchmark com coremark usando as versões mais recentes dos compiladores, LLVM e Cranelift ficaram cerca de 8% mais rápidos no Wasmer v5.0 em comparação com o v4.4.0

Opinião do GN⁺

• O lançamento do Wasmer 5.0 parece ser um marco importante para o ecossistema WebAssembly. Em especial, o suporte a iOS e a oferta de várias opções de backend devem ampliar bastante o alcance do WebAssembly até aplicações móveis
• Ao oferecer suporte a diferentes runtimes como V8, Wasmi e WAMR como backend, os desenvolvedores agora podem escolher o runtime mais adequado às suas necessidades. Isso deve contribuir bastante para aumentar a flexibilidade e a compatibilidade do WebAssembly
• Também merece destaque o esforço de otimização de desempenho por meio do enxugamento da base de código e da adoção de compiladores mais recentes. Isso mostra que o Wasmer não está apenas adicionando recursos, mas também investindo em melhoria contínua de qualidade
• Por outro lado, a descontinuação do suporte aos bindings do Emscripten é um ponto lamentável, mas parece uma escolha razoável, considerando que sua necessidade diminuiu com o surgimento de novos padrões como WASI e WASIX
• No geral, o Wasmer 5.0 é uma release que mostra bem a evolução do WebAssembly, e a expectativa é que o Wasmer continue sendo um dos principais projetos a liderar o ecossistema WebAssembly. Ainda assim, parece necessário um esforço contínuo para aumentar a estabilidade e a maturidade dos recursos que ainda estão em fase experimental

[GN⁺]

Comentários do Hacker News

• Os gráficos de desempenho são confusos e parecem amaldiçoados. Em alguns casos estão em escala logarítmica e, em outros, é difícil entender o que querem dizer. Por exemplo, no gráfico "Argon 2", quase todas as barras aparecem com o mesmo comprimento, mas cada barra mostra números diferentes em milissegundos.
• Ao usar o V8 como backend, passa a haver suporte para tratamento de exceções e coleta de lixo do WebAssembly. Estou esperando por mais novidades relacionadas a isso. Fico me perguntando se o wasm-gc permite compartilhar dados/strings do host entre diferentes módulos dentro do mesmo runtime, ou se isso fica limitado a um único módulo.
• É difícil entender o que o Wasmer faz pela página inicial. Dizem que executa tudo em qualquer lugar, mas não fica claro o que realmente faz. Parece um produto voltado para desenvolvedores, mas há mais buzzwords do que explicações técnicas.
• Estou satisfeito com o Wasmtime e mexendo com o modelo de componentes do WASM e um sistema de plugins baseado em WASI. Está sendo divertido trabalhar nisso.
• Ainda não encontrei um bom caso de uso para aplicar WASM em um projeto. É parecido com a situação de não saber como aproveitar um Raspberry Pi. Não está claro por que eu escolheria WASM para um projeto assíncrono em Rust.
• Queria que existisse uma solução que não exigisse os headers Cross-Origin Isolated. Ainda estou usando uma versão anterior.
• Fico me perguntando se WASM pode servir como uma alternativa mais leve em consumo de recursos para apps Electron. O WASM não tem acesso ao DOM, mas fico na dúvida se isso poderia ser adicionado via extensões.
• Não entendo que problema essa solução resolve. Todo runtime JavaScript já não vem com um motor de WASM embutido?
• Fico me perguntando se essa solução permite avaliar código Node.js com segurança dentro de um sandbox.
• Os gráficos de desempenho são difíceis de ler. Estão usando tanto vírgulas quanto pontos como separadores de milhar, e a precisão está sendo arredondada de forma arbitrária para 1, 2 ou 3 casas.