WebAssembly: o que pode fazer pela tua aplicação web empresarial

Há uns anos desenvolvemos uma aplicação para um cliente do setor industrial que precisava de processar grandes volumes de dados de sensores quase em tempo real. Havia 2 opções: uma aplicação de desktop (cara de distribuir e manter) ou uma aplicação web (lenta para o processamento necessário). Acabámos num meio-termo pouco elegante: uma aplicação web que delegava os cálculos pesados no servidor, com a latência que isso implicava.

Hoje, com WebAssembly, boa parte desse processamento podia ser feita diretamente no browser do utilizador, a uma velocidade próxima da de um programa compilado e sem instalar nada. O WebAssembly não é magia, mas é uma ferramenta poderosa que alarga o que uma aplicação web consegue fazer.

O que é realmente o WebAssembly

O WebAssembly (abreviado Wasm) é um formato de código binário que o browser executa a uma velocidade próxima da nativa. Não é uma linguagem que se escreva diretamente: é um formato de destino para o qual se compilam outras linguagens.

Na arquitetura web tradicional, o browser recebe JavaScript, analisa-o, compila-o em tempo de execução (JIT) e executa-o.

Com WebAssembly, o código escreve-se em C, C++, Rust ou Go, é compilado para Wasm antes de ser publicado e a máquina virtual do browser executa-o diretamente.

O formato foi desenhado para ser analisado e executado depressa, com os tipos definidos à partida, o que poupa ao motor boa parte do trabalho de otimizar uma linguagem dinâmica e torna o desempenho mais previsível. Em código de cálculo intensivo, o resultado é comparável ao de uma aplicação nativa.

Importante: o WebAssembly não substitui o JavaScript. Os módulos Wasm são carregados e invocados a partir de JavaScript, convivem com ele e dependem dele para interagir com o DOM e com as APIs do browser.

Casos de utilização em aplicações empresariais

O WebAssembly destaca-se onde o JavaScript fica aquém em desempenho. No contexto empresarial, isso abre várias categorias:

Processamento de dados no cliente

Se a tua aplicação lida com grandes volumes de dados (dezenas de milhares de linhas, cálculos estatísticos complexos, agregações em tempo real), processá-los no servidor implica latência de rede em cada interação. Com Wasm podes descarregar os dados uma vez e processá-los localmente:

• Análise de vendas com agregações complexas.
• Processamento de logs e geração de relatórios.
• Cálculos financeiros com vários cenários.

Visualização e gráficos avançados

Visualizações 3D complexas, gráficos científicos ou manipulação de imagens de alta resolução:

• Visualização de modelos CAD na web.
• Editores de imagem com filtros complexos.
• Simulações e visualização de dados em tempo real.

Cálculo científico e simulações

Ferramentas que antes exigiam MATLAB, Mathematica ou outro software especializado de desktop:

• Simulações de engenharia para configuradores de produto.
• Modelos preditivos de vendas ou de inventário.
• Algoritmos de otimização complexos.

Criptografia e segurança

Operações criptográficas intensivas feitas localmente, sem enviar os dados para o servidor:

• Geração de chaves e assinaturas digitais.
• Verificação da integridade de documentos grandes.
• Cifragem de dados sensíveis antes de os enviar.

Para operações comuns já existe a Web Crypto API do browser; o Wasm acrescenta valor quando precisas de algo que essa API não cobre.

O que o WebAssembly não é

Tão importante como isso é perceber os seus limites:

Não é mais rápido do que o JavaScript em tudo. Para manipular o DOM, fazer pedidos de rede ou executar lógica de negócio simples, um JavaScript bem otimizado tem o mesmo desempenho. O custo de passar dados entre JavaScript e Wasm pode até torná-lo mais lento em operações pequenas.

Não tem acesso direto ao DOM. Para alterar a página precisa de chamar o JavaScript, o que acrescenta fricção.

Não é portável por artes mágicas. Compilar código C++ para Wasm não garante que funcione bem. O código tem de ser pensado para o ambiente do browser: sem acesso livre ao sistema de ficheiros, com suporte limitado a threads e com memória limitada.

Não substitui as aplicações móveis nativas. O Wasm não acrescenta qualquer acesso ao dispositivo: pode usar o mesmo que a web através de JavaScript, que no telemóvel continua a ser mais limitado do que uma app nativa.

Implementação prática: como começar

Para uma empresa que quer explorar o WebAssembly, a porta de entrada mais simples são as ferramentas que já o usam por dentro.

Nível 1: usar bibliotecas que já usam Wasm

Muitas bibliotecas JavaScript atuais usam WebAssembly internamente sem que dês por isso:

• FFmpeg.wasm: processamento de vídeo no browser.
• TensorFlow.js: aprendizagem automática, com um backend Wasm para as operações intensivas.
• SQLite Wasm: uma base de dados SQL completa no browser.
• magick-wasm: ImageMagick para manipular imagens.

Com estas ferramentas tens as vantagens do Wasm sem escrever uma única linha de código Wasm.

Nível 2: compilar código existente

Se tens bibliotecas em C/C++ ou Rust que queres aproveitar na web:

• Emscripten: compilador de C/C++ para Wasm, o mais maduro.
• Rust com wasm-pack: fluxo de trabalho pensado para levar Rust para Wasm.
• Go e TinyGo: o Go compila para Wasm de forma nativa; o TinyGo gera módulos muito mais leves.

O desafio não costuma ser a compilação, mas adaptar o código para funcionar dentro do ambiente isolado (sandbox) do browser.

Nível 3: desenvolvimento pensado para Wasm desde o início

Para equipas com experiência específica, há linguagens e frameworks que têm o Wasm como destino principal:

• AssemblyScript: linguagem com uma sintaxe semelhante à do TypeScript que compila para Wasm.
• Grain: linguagem funcional desenhada para Wasm.
• Blazor WebAssembly: framework da Microsoft para criar aplicações web com C#.

Um exemplo do nosso trabalho: dados financeiros

Um cliente precisava de uma ferramenta de análise financeira em que os utilizadores pudessem carregar os seus próprios ficheiros CSV com milhares de transações e aplicar filtros, agregações e cálculos complexos de forma interativa.

A primeira versão usava apenas JavaScript. Com ficheiros grandes (mais de 10 000 linhas), o browser bloqueava durante segundos. A segunda processava-os no servidor. Funcionava, mas a latência tirava fluidez a cada filtro.

A versão final usou um módulo WebAssembly escrito em Rust que processava os dados localmente, dentro de um Web Worker para não bloquear a interface. O resultado:

• 50 000 linhas processadas em menos de 100 ms, face aos 3 ou 4 segundos de bloqueio da primeira versão.
• Sem latência de rede nas operações interativas.
• Mais privacidade: os dados sensíveis não saíam do browser do utilizador.

Para sermos justos, parte da melhoria veio de redesenhar o algoritmo, não só da mudança de tecnologia. O custo foi o tempo de desenvolvimento em Rust (novo para a equipa) e a complexidade de pôr JavaScript e Wasm a comunicar. Aqui valeu a pena; para uma tabela de dados simples teria sido engenharia a mais.

Considerações de negócio

Antes de adotar o WebAssembly, faz a ti próprio estas perguntas:

O problema é mesmo de desempenho? Muitos “problemas de desempenho” resolvem-se com melhor JavaScript, carregamento diferido, Web Workers ou um algoritmo mais eficiente. O Wasm é a última opção, não a primeira. E se o que é lento é o carregamento do site, o gargalo costuma estar noutro lado: explicamos isso em como reduzir o tempo de resposta do teu site sem mexer no código.

Tens a experiência técnica? Desenvolver para Wasm exige conhecimentos de programação de sistemas (C, C++ ou Rust) além de web. Se a tua equipa só trabalha com JavaScript, a curva de aprendizagem é acentuada.

O benefício justifica o custo? Desenvolver com Wasm é mais lento e mais caro do que com JavaScript. O benefício tem de ser mensurável: melhor experiência do utilizador, novas capacidades ou menos custos de servidor.

É sustentável a longo prazo? Um módulo Wasm na tua base de código é mais uma dependência técnica, com a sua própria cadeia de compilação. Vais ter capacidade para o manter daqui a 3 anos?

Perguntas frequentes

O WebAssembly é seguro?

O Wasm é executado num ambiente isolado tão restritivo como o do JavaScript e não tem mais acesso ao sistema do que aquele que o JavaScript lhe dá. O risco é o de qualquer código de terceiros: um módulo Wasm malicioso pode fazer o mesmo que um JavaScript malicioso.

Todos os browsers suportam WebAssembly?

Sim. O Chrome, o Firefox, o Safari e o Edge suportam-no desde 2017. As dificuldades estão mais nas ferramentas de desenvolvimento do que na execução.

Posso combinar WebAssembly com WordPress ou Laravel?

Sim. O Wasm vive no frontend: o teu CMS ou framework gera a página que carrega o módulo e, para o servidor, é apenas mais um ficheiro estático.

Devo migrar a minha aplicação para WebAssembly?

Provavelmente não. Uma migração completa raramente se justifica. Identifica as partes concretas com cálculo intensivo e pondera o Wasm só para essas.

Conclusão

O WebAssembly alarga o que uma aplicação web consegue fazer. Para empresas que precisam de processar dados complexos, oferecer visualizações avançadas ou levar software legado para a web, é uma ferramenta valiosa.

Mas não é para toda a gente. A maioria das aplicações web empresariais não precisa de WebAssembly: precisa de JavaScript bem escrito. Reserva o Wasm para os casos em que o desempenho é crítico e o JavaScript não chega.

Se tens um caso que poderia beneficiar do WebAssembly e queres saber se é viável, conta-nos e avaliamos contigo. Às vezes a resposta é “sim, o Wasm é a solução” e às vezes é “não, otimiza primeiro o teu JavaScript”. Ambas as respostas te poupam dinheiro.