JavaScript é a escolha clara para desenvolvimento front-end hoje, mas há um esforço antigo para poder usar Java no front-end. Entre outras coisas, Java traz um vasto ecossistema de bibliotecas, frameworks e código de aplicativo, que pode ser exposto por meio de suas APIs.
Java e linguagens como ela também oferecem otimizações de desempenho que JavaScript não consegue igualar. Historicamente, o sofisticado algoritmo de coleta de lixo do Java era um obstáculo, mas o recente esforço do Google para implementar o suporte de coleta de lixo do Java no Chrome sugere um caminho a seguir. A chave para tudo isso é a extensão de coleta de lixo do WebAssembly, WasmGC.
Planilhas Google e WasmGC
Um dos grandes avanços no desenvolvimento de software é o gerenciamento automático de memória, também conhecido como coleta de lixo . Em alguns cenários de programação, faz sentido para um desenvolvedor mexer diretamente com a memória, mas para aplicativos mais seguros e desempenho ideal, automatizar esses processos geralmente é o caminho a seguir.
O algoritmo de coleta de lixo do Java é uma das opções mais sofisticadas disponíveis, e é por isso que o Google implementou o Googe Sheets no Java. Agora, o Google quer dar um passo além, incorporando o suporte à coleta de lixo do Java diretamente no Chrome, conforme detalhado aqui.
A evolução do Planilhas Google é um conto interessante da história do desenvolvimento web. Começou como um aplicativo de planilha online competindo com aplicativos como o Excel, o que era um empreendimento ambicioso. O aplicativo foi criado usando um backend Java que fazia a maior parte do trabalho pesado. Mas depois de um tempo, o Google modificou esse trabalho para acontecer principalmente no navegador, usando JavaScript.
A mudança para JavaScript incorreu em perdas significativas de desempenho, no entanto, o que levou à decisão de reimplementar o Google Sheets em Java. Mas, dessa vez, a implementação é no front-end, usando Wasm para assembly nativo.
Coleta de lixo no navegador
Wasm é um formato de instrução binária, um tipo de maneira generalizada de descrever o que um programa faz no nível de instrução do assembler. Uma vez que um programa é transformado em um binário Wasm, ele pode ser executado em uma variedade de ambientes de tempo de execução de host.
Existem três tipos básicos de ambientes de host (descritos pelo projeto Wasm como embeddings concretos ): JavaScript, web e WASI (WebAssembly System Interface), a interface de sistema padrão para programas WebAssembly. Esses embeddings mapeiam geralmente para executar o Wasm dentro de um mecanismo JavaScript, dentro do navegador (não necessariamente usando JavaScript) e em outros ambientes como servidores.
Esta é uma simplificação exagerada, mas o que importa para nossos propósitos é que JavaScript já tem um mecanismo de coleta de lixo . Implementar um coletor de lixo dentro de uma plataforma que tem um em execução levanta todos os tipos de problemas e elimina os benefícios de desempenho .
O que precisamos é de uma especificação para implementar o suporte à coleta de lixo diretamente no navegador, onde ele tenha acesso à arquitetura nativa o máximo possível. Isso nos permite fazer otimizações, evitando conflitos com JavaScript. E é aí que o WasmGC entra.
O estado do suporte do navegador para WasmGC
O projeto do Google Sheets está trabalhando com o navegador Chrome , que está implementando a extensão GC para Wasm . Este é obviamente um nexo complexo de requisitos de programação. A coleta de lixo, embora razoavelmente bem compreendida, continua inerentemente complexa. O formato binário universal do Wasm também é muito complexo. Unir os dois é complicado, e o trabalho está em andamento.
Mesmo com essas ressalvas, é emocionante que o Google Sheets esteja se movendo para implementar uma funcionalidade importante na extensão WasmGC do Chrome. Isso sugere que os desenvolvedores podem ser capazes de usar uma linguagem como Java, com seu coletor de lixo completo, fora do JavaScript, às vezes mais cedo do que tarde.
WasmGC e a camada GC emergente
A equipe do Googe V8 publicou um bom mergulho profundo no esforço para implementar a coleta de lixo no Wasm . O artigo mostra que há duas abordagens para incorporar a coleta de lixo no Wasm. A primeira — a que geralmente fizemos no passado — é portar toda a arquitetura. Em essência, isso significa que você traz sua infraestrutura de coleta de lixo com você ao implementar seu aplicativo.
A abordagem oferecida pela extensão WasmGC é mais nova. A extensão fornece uma camada de coleta de lixo genérica à qual seu software pode se referir; um tipo de camada de coleta de lixo incorporada ao WebAssembly.
O Wasm por si só não rastreia referências a variáveis e estruturas de dados, então a adição de coleta de lixo também implica introduzir novas "referências tipadas" na especificação. Esse esforço está acontecendo gradualmente: implementações recentes suportam coleta de lixo em tipos de referência "lineares" como inteiros, mas tipos complexos como objetos e structs também foram adicionados.
Falei com Thomas Steiner , defensor do desenvolvedor no Google Web, sobre o status de tipos complexos no WasmGC. Steiner disse que a implementação inicial do Wasm MVP só era capaz de lidar com números (ou seja, inteiros e flutuantes) na memória linear. Mas com a proposta de tipos de referência sendo enviada e os tipos de heap struct e array adicionados, o Wasm agora pode manter referências externas. Steiner observou que agora, cada objeto WasmGC tem um tipo e estrutura fixos, "o que torna fácil para máquinas virtuais gerar código eficiente para acessar seus campos sem o risco de desotimizações em linguagens dinâmicas como JavaScript".
O ponto principal é que os compiladores de linguagem que visam Wasm podem se integrar com um coletor de lixo na VM host, disse Steiner. Os desenvolvedores que portam uma linguagem de programação para Wasm não precisam mais incluir o coletor de lixo da linguagem como parte da porta. Em vez disso, eles podem simplesmente usar o coletor de lixo existente fornecido pela extensão WasmGC.
Embora ainda esteja em andamento, o formato binário Wasm pode eventualmente incluir uma estrutura de coleta de lixo generalizada na qual todas as linguagens de coleta de lixo (como Java, Python, Kotlin, C#, etc.) poderiam confiar sem trazer sua própria implementação de coleta de lixo.
JavaScript, Wasm e Java
Há também considerações práticas na adoção do WebAssembly em geral e da coleta de lixo em particular. O Wasm é carregado de forma diferente do JavaScript e requer ferramentas diferentes. Tudo aponta para o Wasm expandindo o suporte a idiomas em navegadores da web. Mas isso só acontecerá de forma incremental e com muito cuidado.
O compilador Java para Closure
Para uma visão prática do uso do WasmGC, este exemplo hello world do projeto J2CL (Java to Closure compiler) é um lugar interessante para começar. O projeto J2CL é voltado para fazer Java e JavaScript interoperarem, e está acompanhando os desenvolvimentos do WamsGC na melhoria da capacidade de executar Java diretamente.
Também vale a pena notar que o código Wasm roda junto com o JavaScript e expõe módulos a ele, então não é uma escolha entre um ou outro. Na verdade, o futuro do desenvolvimento front-end provavelmente será JavaScript e , o que significa que JavaScript continua sendo o ponto de entrada para aplicativos, mesmo que muito do trabalho seja transferido para outra linguagem rodando no WebAssembly.
Embora o trabalho pioneiro esteja acontecendo no aplicativo Planilhas do Google e no navegador Chrome (onde o WasmGC agora está ativado por padrão ), o Mozilla Firefox e o Microsoft Edge também oferecem suporte à extensão, assim como os runtimes Deno e Node. Você pode verificar o suporte do WasmGC na página de suporte do Wasm . Em geral, parece que o WasmGC está amadurecendo e se tornando um recurso confiável para plataformas web padrão.
O WasmGC está pronto para uso em produção?
Perguntei a Steiner sobre o uso da extensão WasmGC em aplicativos de produção e ele observou que "WasmGC é uma proposta padronizada (Fase 5 no processo), com implementações em três navegadores e o recurso sendo enviado no Chrome e no Firefox ". Para o Safari, ele disse, a extensão também foi mesclada ao WebKit , mas "ainda não sabemos em qual versão do Safari ela será finalmente enviada". Além disso, "o suporte para WasmGC é detectável por recurso , o que significa que sites e aplicativos como o Planilhas Google podem usar uma abordagem de aprimoramento progressivo: em navegadores que oferecem suporte ao WasmGC, a nova versão é carregada e, em outros navegadores sem suporte, a versão legada existente servirá".
O potencial de desempenho de linguagens como Java sobre JavaScript é uma motivação fundamental para o WasmGC, mas obviamente há também a enorme variedade de funcionalidades e estilos disponíveis entre plataformas de coleta de lixo. A possibilidade de mover código personalizado para o Wasm e, assim, torná-lo universalmente implementável, inclusive para o navegador, está lá.
De forma mais ampla, não se pode deixar de pensar na possibilidade de abrir o navegador para outras linguagens além do JavaScript, o que poderia desencadear uma verdadeira mudança radical na indústria de software. É possível que afrouxar o monopólio do JavaScript no navegador instigue um renascimento da criatividade em linguagens de programação.
Quando perguntei a Steiner se algum dia veríamos aplicativos de navegador Java puro (sem JavaScript), ele disse: "Esse dia, efetivamente, já é hoje. Soluções como o CheerpJ permitem que os desenvolvedores executem aplicativos Java inteiros no navegador, por exemplo, esta demonstração do Swing (dê um pouco de tempo para carregar). É pensado mais para portar aplicativos Java legados para a web, mas, em teoria, se alguém escrevesse um programa Java visando o CheerpJ hoje, eles poderiam executá-lo no navegador. No caso do Planilhas Google, eles usaram o J2Wasm para portar o trabalhador calc do Java para o WasmGC."
Steiner mencionou ainda que outras linguagens como Kotlin podem usar Kotlin/Wasm , e que "Da mesma forma, a equipe do Flutter no Google agora faz uso do WasmGC compilando Dart para WasmGC , e soluções semelhantes existem para SwiftWasm (que ainda não tem como alvo o WasmGC, mas o Wasm regular)."
Conclusão
Eu, pessoalmente, sou um grande fã de JavaScript. É uma maravilha de expressividade e não tenho muitas queixas sobre isso. Por outro lado, estou sempre interessado em como a competição e a polinização cruzada estimulam a inovação.
Olhando para trás, alguns anos a partir de agora, pode ser que o Wasm, como uma camada de implantação universal, crie uma nova fase no desenvolvimento empresarial e web. Silenciosamente, com pouca fanfarra, o trabalho está prosseguindo para tornar essa camada universal mais poderosa e útil. O progresso do WasmGC é um marco tentador na história.
