1) Contexto: por que pensar em alternativas ao WebAssembly?

WebAssembly entrega desempenho próximo ao nativo, isolamento do ambiente de execução e portabilidade entre engines. Contudo, nem todo problema corresponde a um cenário ideal para wasm. Em tarefas de prototipagem, domínios fortemente ligados ao DOM, ou fluxos com latência de inicialização crítica, outras opções podem oferecer melhor tempo de entrega ao usuário ou mais simplicidade de desenvolvimento.

A decisão deve considerar:

• Complexidade de integração com bibliotecas existentes e com o DOM.
• Tempo de carregamento e footprint inicial.
• Necessidade de isolamento, permissões ou sandboxing específico.
• Ecossistema e ferramentas disponíveis para a linguagem escolhida.

2) Quando JavaScript puro faz mais sentido

Em muitos casos, especialmente durante prototipagem rápida ou quando a maior parte da lógica reside em interoperabilidade com o DOM, JS/TS continua sendo a escolha mais ágil. Vantagens incluem:

• Iteração rápida e feedback imediato no navegador.
• Ecossistema robusto de bibliotecas, ferramentas de build e debugging.
• Menor overhead de integração para componentes UI e lógica não computacional intensiva.
• Coeficiente de complexidade menor para equipes que já dominam o ecossistema JS.

Caso o objetivo seja reduzir o custo de CPU para tarefas realmente computacionais pesadas, o caminho pode se dividir entre paralelismo via Web Workers ou migração gradual de famílias de código para WebAssembly quando estratégica.

3) Paralelismo, isolamento e fallback: Web Workers, SharedArrayBuffer e asm.js

Paralelizar trabalho pesado sem bloquear a thread de UI é uma prática essencial. Web Workers permitem execução em segundo plano, com custo mínimo de comunicação via mensagens. Em ambientes legados onde WebAssembly não é suportado, asm.js ainda pode servir como fallback compatível, embora menos eficiente.

Exemplo simples de uso de Web Worker para movimentar cálculo intensivo para outra thread:

// main.js
const worker = new Worker('worker.js');

worker.onmessage = (e) => {
  console.log('resultado:', e.data);
};

const data = { n: 1e7 };
worker.postMessage(data);

// worker.js
self.onmessage = function(e) {
  const { n } = e.data;
  let sum = 0;
  for (let i = 0; i < n; i++) {
    sum += Math.sqrt(i);
  }
  self.postMessage(sum);
};

Observações rápidas:

• Web Workers ajudam a manter a UI responsiva, mas a comunicação entre threads envolve serialização de dados; pense em chunks de dados para diminuir overhead.
• SharedArrayBuffer oferece compartilhamento de memória entre workers, porém exige cabeçalhos de segurança adequados (CS/COOP, COEP) e é mais sensível a políticas de privacidade e sandbox.
• asm.js funciona como fallback mínimo para ambientes sem wasm, mas não substitui wasm em termos de performance em tarefas pesadas.

4) Compute pesado sem wasm: GPU, WebGPU e técnicas de computação

Quando a tarefa é intrinsecamente paralelizável, a GPU pode entregar ganhos significativos. Hoje, as opções evoluem de WebGL/GLSL para WebGPU, que expõem pipelines de computação de forma mais direta e com maior controle de memória.

• WebGPU: ideal para operações numéricas, simulações, image processing e machine learning em pequena escala dentro do navegador.
• WebGL Compute (quando disponível) para tarefas que se beneficiam de shaders de computação, embora menos portátil que WebGPU.
• OffscreenCanvas permite processamento fora do fluxo de rendering da tela, útil para renderização paralela e pipeline de trabalho em background.

Desvantagens a considerar:

• Nível de complexidade de implementação e debugging mais alto do que soluções puramente JavaScript.
• Dependência de suporte do navegador e de capacidades de GPU do dispositivo do usuário.
• Precisão numérica e debugging de código de shader exigem ferramentas especializadas.

Em resumo, quando a tarefa envolve operações massivamente paralelizáveis com grande throughput, explorar GPU pode justificar a complexidade adicional; caso contrário, mantenha a simplicidade com JS + Web Workers.