A Mozilla, a Google, a Microsoft e a Apple decidiram desenvolver um formato binário para a web. Chamado de WebAssembly, este formato pode ser o resultado compilado de qualquer outra linguagem, assim permitindo que aplicações executem no navegador ou em qualquer outro agente.
Alguns anos atrás, foi discutido no InfoQ.com quais as vantagens de haver um bytecode universal para a web (Veja o Debate: Precisamos de um Bytecode Universal para a Web?), exaltando as dificuldades em criar uma. O principal problema mencionado era o desentendimento entre os principais fornecedores de navegadores: A Mozilla empurrava asm.js, a Google estava atrás do PNaCl, a Apple estava trabalhando em FLTJIT, enquanto a Microsoft não mostrou interesse em qualquer um deles. Mas isso mudou, todos os quatro principais fornecedores de navegadores chegaram a um acordo sobre a criação do WebAssembly ou WASM/wasm, um formato binário para a web. Alguns chamam isso de bytecode, mas wasm não é um bytecode no sentido tradicional, como Brendan Eich observou:
"WebAssembly é de fato uma codificação AST após um processo de compressão, não uma pilha bytecode, mas pode ainda chamar de bytecode se preferir".
O projeto estava em modo cauteloso até o momento, mas agora foi tornado público com presença no GitHub e um grupo na comunidade W3C. WebAssembly permite que os programas escritos em outras linguagens (e não somente JavaScript) possam executar no navegador ou em qualquer outro agente de JS, como no servidor, em dispositivo móvel ou loT. Este formato irá eventualmente substituir o asm.js e PNaCl. De acordo com o documento de projeto, que ainda não é definitivo, o WASM usa um binário porque "proporciona eficência: e reduz o tamanho do download e acelera a decodificação, permitindo até mesmo grandes bases de código tenham tempo de inicialização rápida". O WASM tem um formato de texto que o acompanha que pode ser utilizado por depuradores e outas ferramentas do desenvolvedor. As Ferramentas devem ser capaz de traduzir a partir de um formato para o outro, sem qualquer perda de informação.
Um primeiro passo temporário na implementação do WebAssembly foi feito: traduzindo o formato em código correspondente asm.js, por isso já pode ser executado em navegadores que suportam: Firefox, Edge e Chrome. Já existe também um polyfill prototype criado para esta finalidade, e os resultados iniciais mostram que o formato binário gzipped é 20-30% menor do que o correspondente gzipped asm.js, e que decodificação wasm é 23 vezes mais rápida do que a análise do código fonte correspondente no asm.js. O WASM será posteriormente suportado pelas VMs dos navegadores.
WebAssembly vai trazer primeiro programas C/C++ para a web, no entanto, mais tarde pode ser aprimorado para suportar qualquer outra linguagem. Um backend em LLVM e um port do clang são planejados. O WASM executará no "mesmo universo semântico como JavaScript", apoiará chamadas assíncronas para/de JavaScript, permitindo acessar toda as APIs do navegador e obedecer a mesma política de segurança que estão sujeitos os programas atuais implementados em JavaScript. Uma aplicação de cliente pode ser escrito completamente em WASM ou poderia ter o código de negócios no WASM e a UI em HTML/CSS/JavaScript.
Anunciado no aniversário de 20 anos do JavaScript e no mesmo dia que a Ecma anuncionou a versão finalES6, o WebAssembly não é boa notícia para JavaScript: o WASM fará com que seja possível codificar para a web em qualquer linguagem que irá compilar. JavaScript irá competir diretamente com outras linguagens. Devemos esperar para ver Java ou C# compilado para WASM?
WebAssembly se beneficiará de lições aprendidas em desenvolvimento asm.js e PNaCl, uma vez que as respectivas equipes de Mozilla e Google estão envolvidos na sua criação. Tendo a Microsoft e Apple apoiando é muito promissor para o projeto. O único problema é o tempo: geralmente projetos desenvolvidos por várias grandes corporações consome muito tempo. O processo de padronização é lento na maioria do casos.