WebAssembly
Introdução
WebAssembly, ou Wasm, é um recém-chegado à família de tecnologias web (JavaScript, HTML, CSS), tornando-se um padrão oficialmente reconhecido pelo W3C em dezembro de 2019.
O WebAssembly introduz uma nova máquina virtual no navegador, que trabalha ao lado e em estreita colaboração com a máquina virtual JavaScript. É relativamente leve em comparação, com um conjunto de instruções pequeno e um modelo de isolamento rigoroso (o WebAssembly não possui I/O por padrão). Um dos principais motivadores para o desenvolvimento do WebAssembly foi fornecer um destino de compilação para uma ampla variedade de linguagens de programação (C++, Rust, Go etc.), permitindo que os desenvolvedores escrevam novas aplicações web ou portem aplicações existentes com um conjunto mais amplo de ferramentas.
Exemplos de destaque do uso do WebAssembly incluem sua use within Google Earth, onde a aplicação desktop em C++ agora está disponível no navegador, Figma, uma ferramenta de design baseada em navegador que obteve melhorias significativas de desempenho com o uso dessa tecnologia, e mais recentemente o Photoshop que utiliza o WebAssembly por motivos semelhantes.
Metodologia
O WebAssembly é um alvo de compilação, distribuído como módulos binários. Por esse motivo, enfrentamos vários desafios ao analisar o seu uso na web. O Web Almanac de 2021, que é a primeira edição que incluiu o WebAssembly, possui uma seção detalhada sobre a metodologia utilizada, e as respectivas ressalvas. As descobertas aqui, nesta edição de 2022, seguiram a mesma metodologia. A única melhoria adicionada é um mecanismo para determinar o idioma usado para criar os módulos do WebAssembly. A precisão dessa análise é abordada com mais detalhes na seção correspondente.
Quão amplamente o WebAssembly está sendo utilizado?
Encontramos 3.204 solicitações confirmadas de WebAssembly em desktop e 2.777 em dispositivos móveis. Esses módulos são utilizados em 2.524 domínios em desktop e 2.216 domínios em dispositivos móveis, o que representa 0,06% e 0,04% de todos os domínios em desktop e dispositivos móveis, respectivamente.
Isso representa uma modesta redução no número de módulos que descobrimos no rastreamento, uma redução de 16% nas solicitações em desktop e 12% em dispositivos móveis. Isso não significa necessariamente que o WebAssembly esteja em declínio. Ao interpretar essa mudança, vale a pena observar o seguinte:
- Embora você possa usar o WebAssembly para criar todo tipo de conteúdo baseado na web, seu principal benefício é encontrado em aplicativos de negócios mais complexos, com grandes bases de código, que muitas vezes têm vários anos de existência (por exemplo, Google Earth, Photoshop, AutoCAD). Esses “apps” web não são tão numerosos quanto os sites e nem sempre estão disponíveis para o rastreamento do Almanac, que é baseado principalmente nas páginas iniciais, onde o WebAssembly pode ser menos comum.
- Como veremos em uma seção posterior, grande parte do uso do WebAssembly que encontramos vem de um número relativamente pequeno de bibliotecas de terceiros. Como resultado, uma pequena alteração em qualquer uma dessas bibliotecas terá um impacto significativo no número de módulos que encontramos.
Encontramos um número ligeiramente menor (-13%) de módulos WebAssembly servidos para navegadores móveis. Isso não reflete as capacidades do WebAssembly nos navegadores móveis, que geralmente têm suporte excelente. Em vez disso, provavelmente se deve à prática padrão de progressive enhancement, onde, nesses casos, os recursos mais avançados que requerem o WebAssembly não são suportados para usuários móveis.
Ao aplicarmos uma função de hash nos módulos WebAssembly, podemos determinar quantos desses 3.204 módulos - no desktop - são únicos. Ao remover a duplicação de módulos, o número total reduz aproximadamente em um fator de 10, com 383 módulos únicos servidos para navegadores de desktop e 310 para mobile. Isso indica uma quantidade significativa de reutilização - diferentes sites usando o mesmo código WebAssembly, provavelmente através de módulos compartilhados.
Uma proporção significativa de solicitações wasm são feitas a partir de domínios externos, reforçando ainda mais a ideia de que eles são reutilizados. É importante notar que isso aumentou significativamente em relação ao ano passado (67,2% em comparação com 55,2%).
Esses módulos de WebAssembly diferem consideravelmente em tamanho, sendo os menores com apenas alguns kilobytes, enquanto os maiores têm 7,3 megabytes. Ao examinarmos em mais detalhes o tamanho não comprimido, observamos que a mediana (50º percentil) é de 835 kilobytes.
Os módulos menores de WebAssembly provavelmente estão sendo usados para funcionalidades bem específicas, como preenchimento de recursos do navegador ou tarefas simples de criptografia. Os módulos maiores provavelmente são aplicativos inteiros compilados para WebAssembly.
Claramente, o WebAssembly não é amplamente utilizado, e em vez de ver um crescimento no uso, estamos observando uma contração modesta.
Para que o WebAssembly está sendo usado?
- Amazon IVS (Amazon Interactive Video Service) - Aqui, o WebAssembly provavelmente é usado como um codec de vídeo, permitindo a decodificação consistente de vídeo independente do suporte ao codec do navegador do usuário.
- Hyphenopoly - Este é um módulo npm que fornece um polyfill para hifenização CSS. O algoritmo principal é enviado como um módulo WebAssembly, proporcionando uma pequena pegada e desempenho consistente.
- Blazor - O Microsoft Blazor é uma plataforma - runtime e biblioteca de interface do usuário - que suporta o desenvolvimento de aplicações web usando a plataforma .NET e C#.
- ArcGIS - Uma suíte abrangente de ferramentas para construir aplicações de mapeamento interativas. O desempenho é uma preocupação principal para a equipe do ArcGIS, e eles utilizam várias tecnologias como WebGL para alcançar isso. Especificamente, o WebAssembly é usado para permitir projeções rápidas do lado do cliente.
- CanvasKit - Essa biblioteca oferece capacidades mais avançadas do que a API padrão Canvas2D. É implementada por meio do Skia, uma biblioteca gráfica escrita em C++, que é compilada para WebAssembly permitindo a execução no navegador.
- Tableau - Uma ferramenta popular para criar visualizações interativas. Não está claro se o WebAssembly é usado como parte do produto principal deles ou se está sendo usado apenas para os painéis específicos que foram encontrados durante o rastreamento.
- Draco - Uma biblioteca para compressão e descompressão de malhas geométricas 3D e nuvens de pontos. É escrita em C++ e o uso do WebAssembly permite sua utilização no navegador.
- Xat - Uma rede social. Não está claro para que eles estão usando o WebAssembly.
- Hewlett Packard Enterprise - Não está claro para que eles estão usando o WebAssembly.
Ao observarmos as bibliotecas populares do WebAssembly, podemos ver que seu uso é bastante específico, muitas vezes sendo utilizado para tarefas específicas de cálculos numéricos ou aproveitando grandes e maduros conjuntos de código em C++, trazendo suas capacidades para a web sem a necessidade de portar para JavaScript.
Que linguagens as pessoas estão usando?
O WebAssembly é um formato binário e, como resultado, muitas informações do código-fonte - como a linguagem de programação, a estrutura do aplicativo e os nomes das variáveis - são obfuscadas ou completamente perdidas durante o processo de compilação.
No entanto, os módulos geralmente têm exportações e importações que nomeiam funções dentro do ambiente de hospedagem - a execução de JavaScript dentro do navegador - que descrevem a interface do módulo. A maioria das cadeias de ferramentas do WebAssembly cria uma pequena quantidade de código JavaScript, com o propósito de ’vinculação’, tornando mais fácil integrar módulos em aplicativos JavaScript. Essas vinculações muitas vezes possuem nomes de função reconhecíveis que estão presentes nas exportações ou importações dos módulos, proporcionando um mecanismo confiável para identificar a linguagem usada para criar o módulo.
Aprimoramos o projeto wasm-stats, que fornece análises específicas para WebAssembly ao rastreador, adicionando código que inspeciona exportações / importações para identificar padrões comuns que indicam a linguagem usada para criar um determinado módulo. Como exemplo, se um módulo importa um módulo com o nome wbindgen , isso é uma referência a código gerado pelo wasm-bindgen e um claro indicativo de que o módulo foi escrito em Rust.
Em alguns casos, os nomes de exportação/importação são minificados, tornando mais difícil identificar a linguagem de origem. No entanto, o Emscripten (uma cadeia de ferramentas de C++) possui uma convenção distintiva para nomes minificados, o que significa que podemos ter uma confiança relativa de que os módulos que exibem esse padrão foram gerados usando o Emscripten.
Analisando os resultados, descobrimos que, no desktop, 72,8% dos módulos foram muito provavelmente criados usando o Emscripten e, como resultado, são muito provavelmente escritos em C++. Em seguida, a linguagem mais popular é o Rust, com 6,0%, seguida por Blazor (C#) com 3,5%. Também encontramos um pequeno número de módulos escritos em Go.
Notavelmente, 16,9% dos módulos não possuíam uma linguagem identificável. AssemblyScript é uma linguagem popular específica para WebAssembly que não fornece pistas óbvias nos módulos que produz. Sabemos que Hypehnopoly, que representa 8,2% de todos os módulos, usa AssemblyScript, e isso representa quase metade desses módulos “não identificados”.
É interessante contrastar esses resultados com a State of WebAssembly 2022 survey, onde Rust foi a linguagem mais utilizada com maior frequência. No entanto, um número significativo de respondentes dessa pesquisa estava usando o WebAssembly para aplicações fora do navegador.
Quais recursos estão sendo utilizados?
O lançamento inicial do WebAssembly foi considerado um MVP (Produto Viável Mínimo). De acordo com outros padrões da web, ele está em constante evolução sob a governança do World Wide Web Consortium (W3C). Este ano marcou o anúncio do rascunho do WebAssembly v2 draft, adicionando vários novos recursos.
Analisamos as funcionalidades pós-MVP que estão sendo utilizadas e encontramos que a extensão de sinal (um aprimoramento relativamente simples que adiciona operadores que permitem estender os valores inteiros para uma maior profundidade de bits) foi de longe a mais utilizada. Isso não representa uma diferença significativa em relação ao resultado encontrado na análise do ano passado..
Vale ressaltar que, enquanto os desenvolvedores web se deparam com a escolha de quais recursos de HTML / JavaScript / CSS utilizar, com o WebAssembly essa decisão muitas vezes é tomada pelos desenvolvedores da cadeia de ferramentas. Como resultado, é provável que veremos um aumento na adoção de recursos pós-MVP quando uma determinada cadeia de ferramentas determinar que eles são agora uma opção viável.
Conclusões
WebAssembly é indiscutivelmente uma tecnologia de nicho quando se trata da web, e há uma grande chance de que sempre seja assim. Embora o WebAssembly tenha trazido uma ampla variedade de linguagens para a web - C++, Rust, Go, AssemblyScript, C# e outras - ainda não é possível usá-las de forma intercambiável com o JavaScript. Para a grande maioria dos sites, onde o conteúdo é relativamente estático (renderizado em HTML com CSS) e com uma quantidade modesta de interatividade (por meio do JavaScript), simplesmente não há uma razão convincente para usar o WebAssembly no momento.
Existem algumas propostas significativas que podem mudar isso no futuro. Inicialmente, o WebIDL, que foi substituído por Interface Types, que por sua vez foi substituído pela especificação Component Model. Essas mudanças podem resultar em um futuro onde será possível trocar facilmente o JavaScript por qualquer outra linguagem de programação, mas por enquanto, isso simplesmente não é o caso.
Apesar de ser uma tecnologia de nicho, o WebAssembly já está agregando valor à web. Existem várias aplicações web que se beneficiam muito dessa tecnologia. No entanto, as aplicações web muitas vezes não são visíveis para a ’busca’ que serve de base para este estudo.
Por fim, as características principais do tempo de execução do WebAssembly - multi-linguagem, leve e seguro - estão tornando-o uma escolha popular para uma ampla gama de aplicações não relacionadas ao navegador. A pesquisa State of WebAssembly 2022 survey sviu um aumento significativo no número de pessoas usando essa tecnologia para aplicações serverless, containerização e plug-ins. O futuro do WebAssembly pode ser como uma tecnologia web de nicho, mas também como um tempo de execução totalmente mainstream em uma ampla variedade de outras plataformas.
