Depois de iniciativas como o asm.js, em que o objetivo é trazer a performance de aplicações desktop (que tipicamente usam linguagens compiladas ahead-of-time, como C/C++) para o browser, começou um esforço conjunto entre a Google, Mozilla, Microsoft, Apple e o W3C para definir um standard de “Assembly para a web”, ou seja, bytecode que todos os browsers soubessem interpretar.

Hoje foi feito um anúncio conjunto entre equipas do Chrome (V8), Firefox (SpiderMonkey) e Edge (Chakra) de que o WebAssembly chegou à fase de browser preview, ou seja, é agora possível experimentar uma demo em todos os browsers excepto no Safari (se bem que para o Edge é preciso usar a build de development).

Isto são boas notícias porque, quanto mais não seja, é impressionante ver um jogo feito em Unity a correr com tanta fluidez num browser (que é algo que foi inicialmente pensado para mostrar texto e, quanto muito, algumas imagens).

No entanto, para mim a melhor notícia de todas é que FINALMENTE todo o desenvolvimento web deixará de estar preso a uma só linguagem de programação. Atualmente todas as linguagens que queiram ser usadas para desenvolvimento web têm inevitavelmente que ser compiladas para JavaScript (como Elm ou ClojureScript), o que introduz complexidade para quem desenvolve linguagen, já que é obrigado a desenvolver a compilação texto-para-texto só para acabar por ter uma linguagem alvo que para ser executada tem que haver parsing do texto!

Fora a questão de evitar o parsing, que para programas grandes em dispositivos móveis pode demorar até 40s, usar bytecode em vez de JavaScript tem outras vantagens como a facilidade em adicionar novas features (incluindo melhores profilers, debuggers, excepções de custo zero ou manipulação direta de memória, dentro de uma sandbox, à la C/C++) e integrar perfeitamente com a toolchain de LLVM, o que permite que várias outras linguagens compilem para WebAssembly facilmente, tendo “apenas” que desenvolver um novo backend para o compilador.

Outra grande esperança que WebAssembly traz e que merece um parágrafo por si só é a possibilidade de programar com POSIX threads. Até à data multithreading no browser é feito via WebWorkers, o que é limitado pela forma como se passa informação (mensagens em vez de memória partilhada) e pelo tipo de threads que usa (OS threads em vez de coroutines/fibers/lightweight threads/green threads).

De qualquer forma, JavaScript tão cedo não vai deixar de ser um cidadão de primeira classe na stack da web e por isso está previsto existir suporte para chamadas síncronas entre JavaScript e WebAssembly, o que permite uma migração progressiva, ou então apenas usar o novo standard em secções do programa em que o desempenho seja crítico.