Quais são as diferenças entre o WebAssembly e a JVM?

Em sua essência, tanto a JVM quanto o WebAssembly foram projetados para executar código compilado em praticamente qualquer lugar: para a JVM, isso significava máquinas com diferentes sistemas operacionais ou arquiteturas de CPU, algo sem precedentes para a época, e para o WebAssembly, isso significava qualquer navegador da web em qualquer computador em qualquer lugar, pelo resto dos tempos.

A JVM, introduzida em meados da década de 1990 junto com o Java, evoluiu para uma plataforma completa que fornece suporte avançado de tempo de execução — coleta de lixo, extensas bibliotecas padrão e ferramentas para execução gerenciada. No entanto, alguns podem dizer que isso dá à JVM uma quantidade considerável de inchaço: grandes volumes de memória e tempos de inicialização mais lentos. Embora extremamente poderosa, isso torna a JVM menos adequada para applications leves.

Em contraste, o WebAssembly foi projetado com a web em mente, especificamente para executar código dentro de navegadores. Como resultado, ele foi arquitetado para priorizar um tempo de execução leve e tempos de inicialização extremamente rápidos, mas sem o suporte avançado de tempo de execução. A segmentação apenas de navegadores tornaria o Wasm menos portátil que o bytecode Java, mas hoje, os tempos de execução autônomos do Wasm podem ser executados fora da web, abrindo novas portas para applications do lado do servidor, sistemas embarcados e computação de borda. Além disso, algum suporte de tempo de execução adicional limitado está chegando ao WebAssembly, ou seja, coleta de lixo, mas é improvável que vejamos toda a amplitude de suporte de tempo de execução no WebAssembly que a JVM oferece.

A JVM só funciona com sua família de linguagens — Java, Kotlin, Scala e algumas outras — todas elas projetadas intencionalmente para serem executadas na JVM. Embora o ecossistema Java tenha extensas bibliotecas e estruturas, a interoperabilidade só acontece entre essas linguagens JVM. Applications baseados em JVM podem chamar código nativo, mas não sem grande esforço e cuidado.

O WebAssembly não foi projetado para oferecer suporte apenas a uma linguagem de programação ou para favorecer um certo estilo de linguagem, seja ela funcional, coletada de lixo ou interpretada. Qualquer linguagem — Rust, JavaScript, Python, C++ — pode ser compilada para rodar em um ambiente de execução Wasm. Embora isso não signifique que o código de cada uma dessas linguagens seria capaz de se comunicar agora, por meio do padrão emergente do Modelo de Componentes , os desenvolvedores podem pegar vários módulos Wasm escritos em diferentes linguagens e conectá-los perfeitamente. Em breve, para o WebAssembly, a vinculação e a interoperabilidade serão garantidas.

Quando foi a última vez que você ouviu falar que alguém incorporou a JVM em um application para executar plugins ou lógica personalizada? Não recentemente, se é que alguma vez aconteceu, não é? Embora a JVM seja poderosa, é notoriamente desafiador incorporá-la a outros applications. Algumas incorporações de alto nível aconteceram (como applets Java em navegadores), mas elas caíram em desuso devido à sua desajeitamento ou manutenibilidade.

O WebAssembly, por outro lado, foi projetado para incorporação. Incorporar um tempo de execução Wasm em um application geralmente é tão fácil quanto obter uma nova biblioteca. Uma vez feito isso, seu application pode executar código Wasm — isso pode ser para estender um mecanismo de jogo, modificar um algoritmo, responder a um evento ou qualquer outra coisa que você possa imaginar. O Wasm oferece versatilidade em incorporação que a JVM não está equipada para oferecer (ou não quer oferecer, nesse caso).

É sem dúvida aqui que o WebAssembly brilha mais. A JVM tem seu próprio modelo de segurança, mas foi projetado sob a suposição de que o código executado é confiável. O WebAssembly rejeita fundamentalmente essa premissa — nascido no navegador, onde visitar um site necessariamente baixa código não confiável e o executa, o Wasm emprega um modelo de sandbox rigoroso de negação por padrão. Ele não concede acesso de código aos recursos do sistema, memória ou outras funcionalidades, a menos que seja explicitamente autorizado. Essa abordagem minimiza inerentemente as superfícies de ataque e torna o Wasm ideal para ambientes onde a execução de código não confiável é uma preocupação.

O modelo de segurança da JVM é funcional, mas não foi projetado para o nível de segurança que o Wasm oferece.

A JVM é uma veterana experiente no mundo da tecnologia. Com décadas de história, ele conta com uma tremenda adoção, amplas ferramentas empresariais e uma comunidade tão vasta que parece uma força inabalável no desenvolvimento de software. Sabemos que ele não vai desaparecer tão cedo. Se longevidade e estabilidade comprovada são essenciais para seus casos de uso, a JVM oferece isso.

O WebAssembly, por sua vez, ainda é o novato no pedaço. Apesar de ser mais jovem e estar perto de completar 10 anos, o entusiasmo em torno do Wasm está crescendo a um ritmo exponencial. Embora menos maduro que a JVM hoje, a trajetória do WebAssembly sugere um futuro brilhante.

Tanto o WebAssembly quanto a JVM são tecnologias incríveis, cada uma se destacando em maneiras que se adaptam aos seus ambientes e casos de uso. A JVM prospera em fluxos de trabalho corporativos onde applications completos e recursos avançados de tempo de execução são importantes. Por outro lado, a capacidade de incorporação, o tempo de execução leve, a compatibilidade entre idiomas e a segurança incomparável do Wasm o tornam uma escolha atraente para plug-ins e computação de borda.

Então, qual você deve escolher? Se você estiver desenvolvendo applications autônomos com necessidades robustas de tempo de execução, a JVM continua sendo uma escolha prática e testada pelo tempo. Mas se você quer flexibilidade entre idiomas ou a capacidade de se conectar a aplicativos existentes com facilidade, o WebAssembly pode ser a solução.