No início do que é conhecido como a World Wide Web, existia o JavaScript. O JavaScript existe desde 1995, quando Brendan Eich criou a linguagem para suportar o Netscape, um navegador da web que infelizmente não existe mais, mas que era revolucionário para a sua época. Desde então, o padrão ECMAScript tem servido como base para o desenvolvimento da web, representando a vasta maioria das aplicações que rodam no navegador web.

Mais recentemente, o WebAssembly (Wasm) - que na verdade já existe há algum tempo - surgiu. Depois que o World Wide Web Consortium (W3C) o nomeou como um padrão da web em 2019, ele se tornou o quarto padrão da web, junto com HTML, CSS e JavaScript. Mas, enquanto as aplicações de navegador web representaram o caso de uso central e histórico do Wasm, o ponto é que ele foi projetado para funcionar em qualquer lugar em um CPU configurado adequadamente - é aí que o Wasm e o JavaScript se separam e se integram para alguns casos de uso.

Wasm e JavaScript continuam fortemente ligados, mas o Wasm é muito mais do que apenas JavaScript. Em resumo, o propósito original do Wasm de ajudar o JavaScript a funcionar de forma mais eficiente no navegador web ainda é um componente-chave de sua integração. Essa integração agora se estende além do navegador web, e em aplicações de borda e servidor para as quais o JavaScript sozinho não foi a melhor escolha.

Isso se deve à forma como o Wasm executa em formato binário em um nível de CPU. E não esqueçamos, ao contrário do JavaScript, o Wasm não é uma linguagem de programação. Uma das principais vantagens do Wasm é que sua funcionalidade permite que ele acomode uma série de diferentes linguagens, além do JavaScript, incluindo Python, Rust, é claro, bem como Go, .NET, C++, Java e PHP.

Então, o WebAssembly pode integrar o JavaScript quando necessário, mas não está limitado a integrar apenas o JavaScript, é claro. Essa integração e uso com o JavaScript tem sido a pedra angular da simbiose entre WebAssembly e JavaScript, especialmente na esfera de aplicações da web.

Isso porque o Wasm pode dar ao JavaScript um impulso de performance compilando a linguagem interpretada, e seu tempo de execução, em módulos Wasm, disse Torsten Volk, analista da Enterprise Management Associates (EMA), a The New Stack. O código já compilado geralmente executa mais rapidamente do que o código que ainda precisa ser interpretado em tempo de execução, como o JavaScript, ele disse.

A integração entre Wasm e JavaScript funciona bem para uma ampla gama de aplicações. Isso inclui aprendizado de máquina baseado em navegador em locais de borda, jogos de navegador com alta exigência de performance, aplicativos de realidade aumentada e virtual que exigem execução de baixa latência e, em geral, aplicativos que precisam iniciar rapidamente, disse Volk.

Além disso, enquanto o JavaScript é uma ótima linguagem de propósito geral, às vezes faz sentido "poder jogar com as forças de outra linguagem", disse Matt Butcher, CEO e cofundador da Fermyon Technologies, a The New Stack. "O processamento intensivo de números pode ser implementado de maneira mais eficiente em C++ ou Rust. Um pacote em Python pode já fazer exatamente o que você precisa", disse Butcher. "Ou você pode estar preso a um código complexo de legado que realmente precisa ser executado no navegador. O WebAssembly desbloqueia esses casos de uso".

Uma História Compartilhada

De fato, a co-evolução histórica de JavaScript e WebAssembly é complementar, já que o Wasm foi criado cerca de 20 anos depois do JavaScript, visando expandir os casos de uso do JavaScript para cargas de trabalho de aplicativos com maior exigência de desempenho, disse Volk.

"Para o desempenho puro de computação, bem como para tarefas como processamento de imagens, o WebAssembly certamente mostrou seu mérito como sendo muito mais rápido que o JavaScript. Mas argumenta-se que o contexto é muito mais complexo que isso", disse Volk. "Não é realmente uma questão o tempo todo se os tempos de computação mais rápidos importam tanto, como a necessidade de código JavaScript para tarefas de codificação mais leves para aplicativos móveis e da Web".

Enquanto o modelo de interação do WebAssembly pode ter sido histórico para criar uma forma para o código JavaScript baseado em navegador interagir com bibliotecas escritas em outras linguagens, é o resultado do design do WebAssembly que tem se mostrado mais importante, disse Butcher. "O WebAssembly faz poucas suposições sobre o ambiente externo. Importante, ele não assume o JavaScript", disse ele. "Isso fez com que fosse fácil para o Wasm evoluir além do contexto do navegador".

A especificação do novo modelo de componente é um exemplo disso. Isso porque descreve como qualquer binário WebAssembly pode importar e exportar funções para serem consumidas por qualquer outro binário WebAssembly, disse Butcher. "Nenhum JavaScript necessário - isso vai bem além do escopo original do WebAssembly, mas pode ser alcançado devido à forma como a especificação original foi escrita", disse Butcher.

Pode-se dizer que o WASM é melhor?

Quando se trata de desempenho de computação puro ou tarefas como processamento de imagens, o WebAssembly certamente demonstrou ser muito mais rápido do que o JavaScript. Mas é controversa a questão de se o tempo de computação mais rápido realmente é importante em todas as situações, como na necessidade de código JavaScript para tarefas de codificação mais leves em aplicativos móveis e da Web.

"No navegador, acho que a maior vantagem do WebAssembly é a potencial utilização de bibliotecas de outras linguagens. O desempenho é bom e pode ser útil para aplicações da Web, como o Figma. Mas a reutilização de código é amplamente aplicável a muitas aplicações da Web", disse Butcher.

"Para o ecossistema de navegadores, eu acho que não veremos o WebAssembly ultrapassar sua natureza assistente e fornecerá vantagens adicionais ao JavaScript, sem deslocá-lo. O verdadeiro potencial do WebAssembly está além do navegador, onde seu perfil de segurança, desempenho e facilidade de desenvolvimento o tornam um ajuste perfeito para inovação na nuvem", disse ele.

Desde que o JavaScript é uma linguagem acessível a quase todos e oferece muitas bibliotecas apoiadas pela comunidade que "suportam muitos casos de uso sem a necessidade de reinventar a roda", notou o Volk. "O fato de que o Wasm pode ser combinado com o ReactJS e outros frameworks populares de JavaScript amplia ainda mais a gama de casos de uso para o JavaScript, permitindo que os desenvolvedores entreguem aplicativos corporativos completos de maneira simples e responsiva", disse Volk.

Segurança

Wasm oferece vantagens de segurança em comparação ao código implantado apenas em JavaScript. O Wasm serve para tornar o código JavaScript mais seguro quando o Wasm é usado como um "compilador em esteróides" com o qual as aplicações JavaScript podem ser implantadas. Por exemplo, o Wasm isola o JavaScript do navegador, garante a segurança da memória e implementa variáveis fortemente tipadas que são mais difíceis de serem exploradas em comparação às variáveis dinamicamente tipadas do JavaScript. “No geral, executar JavaScript no Wasm proporciona uma ótima "atualização de segurança" para todo o aplicativo”, disse o Volk.

De fato, o Wasm oferece vantagens de segurança em vários aspectos. Isso porque, como comunicou Sounil Yu, chefe de segurança da informação da JupiterOne, provedora de soluções de gestão e governança de ativos cibernéticos:

• O Wasm como compilador para o JavaScript pode melhorar a segurança da aplicação reduzindo a superfície de ataque à vulnerabilidade, fornecendo melhor segurança de memória, obscurecendo o código, sandboxando o ambiente de execução e aproveitando um ecossistema de segurança existente. O Wasm tem um conjunto limitado de instruções e melhor gerenciamento de memória, o que ajuda a reduzir a superfície de ataque para vulnerabilidades e previne alguns tipos comuns de vulnerabilidades, como overflow de buffer
• O código Wasm oferece um pouco de segurança por meio da obscuridade, não sendo legível por humanos, tornando mais difícil para os atacantes reengenhar o código e, portanto, mais difícil de descobrir e explorar vulnerabilidades.
• O Wasm também pode ser executado em um ambiente sandbox, o que pode ajudar a isolar o código do resto do sistema para impedir que ele acesse informações sensíveis ou realize operações ilegais.
• Os frameworks Wasm, como o wasmCloud da CNCF, estendem a pegada de segurança do Wasm ainda mais, fornecendo abstrações de nível superior e reduzindo a quantidade de código que os desenvolvedores incorporam em cada aplicação. O wasmCloud também alivia a carga de segurança para os desenvolvedores, tornando mais fácil assinar artefatos, habilitar monitoramento incorporado e automatizar a correção de aplicativos.
  

Mas não podemos dizer que o JavaScript é intrinsecamente inseguro. De fato, o Javascript "pode ser feito bastante seguro", como afirmou Ralph Squillace, gerente de programa principal da Microsoft, Azure Core Upstream, em uma resposta por e-mail. "Os navegadores são algumas das superfícies mais atacadas do planeta. No entanto, o WebAssembly torna mais fácil defender com uma modelo de sandbox matematicamente comprovável, que ferramentas como Veriwasm aproveitam", disse Squillace.

"Além disso, você pode usar o modelo de componentes futuro para restringir a superfície de ataque - o host, por exemplo, pode nem mesmo oferecer uma API de sistema de arquivos - e no mundo futuro esses tipos de restrições serão críticas", afirmou Squillace. "Mas não se deixe enganar: os hosts ainda podem cometer erros de configuração e conceder muito poder a um módulo!".