- Desde seu primeiro lançamento em 2017, o WebAssembly evoluiu com suporte à execução de linguagens de baixo nível como C/C++, mas ainda é tratado como uma linguagem de segunda classe na plataforma web
- Apenas o JavaScript consegue interagir diretamente com as Web APIs, e o WebAssembly precisa escrever um código de binding em JS (glue code) complexo para isso
- Essa estrutura leva à complexidade no processo de carregamento, overhead de desempenho e fragmentação do toolchain por linguagem, prejudicando a experiência do desenvolvedor
- Para resolver isso, a Mozilla propõe o WebAssembly Component Model, que permite chamadas a Web APIs e carregamento de módulos de forma padronizada sem JS
- Se esse modelo se consolidar, o WebAssembly poderá se estabelecer como um ambiente de execução de primeira classe dentro do navegador, criando uma base para que desenvolvedores em geral possam usá-lo com facilidade
Por que o WebAssembly é tratado como uma linguagem de segunda classe
- O WebAssembly só consegue acessar a plataforma web por meio do JavaScript, e não tem permissão para chamar Web APIs diretamente
- O JavaScript pode ser carregado de forma simples com a tag
<script>, mas o WebAssembly exige um processo manual de carregamento via JS API
- É preciso passar por chamadas de API mais complexas, como
WebAssembly.instantiateStreaming(), e o desenvolvedor precisa memorizá-las ou automatizá-las com ferramentas
- A proposta esm-integration simplifica o processo de carregamento ao permitir importar arquivos
.wasm diretamente pelo sistema de módulos do JS
- Carregamento direto no formato
<script type="module" src="/module.wasm"></script>
Limitações no acesso às Web APIs
- Em JavaScript, uma tarefa que pode ser feita com uma única linha,
console.log("hello, world"), no WebAssembly exige procedimentos complexos como acesso à memória do JS, decodificação de strings e encapsulamento de funções
- Como o WebAssembly não consegue acessar o objeto
console nem o DOM, é necessário fazer chamadas indiretas em JS por meio de compartilhamento de memória e import/export de funções
- O código de binding (glue code) gerado nesse processo varia conforme a linguagem e é criado automaticamente por ferramentas como
embind e wasm-bindgen
- Porém, isso causa aumento da complexidade de build, overhead em tempo de execução e problemas de incompatibilidade entre linguagens
Motivos técnicos pelos quais o WebAssembly ainda não se tornou uma linguagem de primeira classe
- Dificuldade de integração de compiladores: o compilador de cada linguagem precisa gerar separadamente o código de integração com JS e com a plataforma web, e isso não pode ser reutilizado
- Incompatibilidade dos compiladores padrão: um arquivo gerado com
rustc --target=wasm não roda diretamente no navegador
- É necessário instalar separadamente um toolchain não oficial que implemente a integração com a plataforma
- Viés do ecossistema de documentação: a maior parte da documentação web, como a do MDN, é escrita com foco em JavaScript, o que eleva a barreira de entrada para usuários de outras linguagens
- Problema de desempenho: chamadas ao DOM passando por bindings em JS apresentam queda de desempenho de 45% em comparação com chamadas diretas
- Em experimentos com o framework Dodrio, ao remover o glue em JS, o tempo para aplicar mudanças no DOM caiu pela metade
- Dependência de JavaScript: para usar WebAssembly em contextos reais, no fim das contas é preciso entender JS, o que leva ao problema de abstração vazando (leaky abstraction)
A chegada do WebAssembly Component Model
- O WebAssembly Component Model define uma unidade de execução padronizada que pode ser usada em comum por várias linguagens e runtimes
- Ele permite realizar acesso a Web APIs, carregamento de módulos e linking diretamente, sem JS
- Pode ser gerado por várias linguagens e é compatível com execução em vários runtimes, como navegadores e o Wasmtime
- Por meio do WIT (Interface Description Language), é possível declarar as APIs necessárias e chamá-las diretamente de dentro do componente
- O navegador pode carregar o componente diretamente com
<script type="module" src="component.wasm"></script> e fazer automaticamente o binding com Web APIs sem JS
Interoperabilidade com JavaScript
- O Component Model também oferece suporte a uma arquitetura híbrida de apps
- Ex.: escrever um decodificador de imagens em WebAssembly e chamá-lo em JS no formato
import { Image } from "image-lib.wasm";
- O JS pode usar componentes WebAssembly importando/exportando como módulos comuns
Perspectivas futuras e participação
- A Mozilla está trabalhando na padronização do Component Model em colaboração com o WebAssembly CG, e o Google também está em fase de avaliação
- Desenvolvedores podem experimentar no navegador ou na CLI por meio do Jco ou do Wasmtime
- Se esse modelo se consolidar, o WebAssembly poderá se expandir de “um recurso para power users” para uma tecnologia web utilizável também por desenvolvedores em geral
4 comentários
Isso está mais para um desejo típico da Mozilla. O front-end não consegue escapar estruturalmente do sistema límbico da reação do mercado. Assim que o WebAssembly apareceu, o Doom 3 já foi portado. O DOM já se transformou há muito tempo em objetos proxy leves nos navegadores modernos e, considerando o conjunto de instruções dedicado a JavaScript das CPUs modernas e o limite quântico de single-core, algo assim jamais vai conquistar uma vantagem em valor de mercado.
Que sentido faz um binário de WebAssembly rodando dentro do Electron? Isso parece só mais uma caça por prestígio de port para Rust, tipo outro GitKraken CLI.
Se tem uma coisa que me anima, é a ideia de inserir um módulo wasm como arquivo, tipo
<script type="module" src="/module.wasm"></script>E também preciso dizer que é absurdo afirmar que a barreira de entrada do WebAssembly é alta. É só que a necessidade disso é menor do que a disposição para pagar. Quer velocidade e baixo footprint, mas também quer usar DOM e CSS? Que tipo de comédia pastelão é essa?
Comentários do Hacker News
É uma pena terem abandonado a meta inicial de dar suporte a WebIDL no WebAssembly e, ao decidir criar outra IDL, não terem tratado a falta de acesso ao DOM como um problema
Claro que entendo a realidade do mercado, mas não consigo deixar de achar lamentável o tempo perdido
Links relacionados: registro do commit, retrospectiva sobre stringref, artigo da ACM
Depois, dois objetivos adicionais foram incluídos: um era suporte a APIs fora da web, e o outro era interoperabilidade entre linguagens
WebIDL é a união de JS com Web API, então tem alta expressividade, mas também muitos conceitos que entram em conflito com esses objetivos
Por isso, a interface de componentes adotou uma abordagem de interseção muito mais portável, embora menos expressiva
Pessoalmente, acho o acesso ao DOM importante, mas o Wasm CG estava ocupado com outras prioridades
Escrevi este texto porque queria deixar claro que ainda nos lembramos desse problema e que planejamos continuar trabalhando nele
A toolchain e o processo de build são complexos demais, e sinto uma carga cognitiva toda vez que preciso usar isso
O desempenho é muito melhor sem glue, mas isso também aumenta os fatores de risco
Espero que o modelo de componentes não introduza uma nova camada de complexidade, mas os exemplos em várias linguagens já parecem bastante confusos
Em especial, ao ver o exemplo em Go, há arquivos gerados demais, e do ponto de vista do desenvolvedor a simplificação do tooling é urgentemente necessária
No momento, parece que não estamos eliminando a complexidade, apenas movendo-a de lugar
Houve muito churn porque a especificação de wasm component continuou mudando
O objetivo é que desenvolvedores web não precisem escrever WIT diretamente, e possam usar Web APIs como se fossem bibliotecas
Mas ainda há um longo caminho pela frente
Por exemplo, se fossem divididas em compartilhamento de texto, compartilhamento de mídia, compartilhamento de aplicativos etc., a segurança melhoraria e equipes pequenas também poderiam criar alternativas a navegadores
Mas a escala gigantesca das Web APIs e do CSS parece sustentar o monopólio dos navegadores, então esse tipo de tentativa deve ser difícil
Seria bom padronizar um registro de WebAssembly para que componentes pudessem ser combinados com facilidade
No fim, a web é o processo de construir a definição de um sistema operacional distribuído
Ele organiza bem desde os conceitos até exemplos de código
No ecossistema JS, os três projetos centrais são StarlingMonkey, ComponentizeJS e jco
Hoje a toolchain mais madura é a de Rust, mas o suporte a linguagens baseadas em LLVM (C/C++, Go, Python etc.) também está melhorando gradualmente
O objetivo do WebAssembly é se tornar um alvo de compilação que se integra naturalmente à toolchain local
Se ainda for preciso entender glue code específico por linguagem ou dois modelos de runtime, o WebAssembly continuará sendo apenas uma “ferramenta para situações extremas”
Para realmente provocar mudança, é preciso simplificar o caminho de build comum
Não está claro como o Component Model lida com isso
O DOM varia de navegador para navegador, e os recursos mudam a cada carregamento de página
Na camada de ponte com JS, é fácil aplicar polyfills, mas em interfaces WIT é difícil fazer detecção de métodos em runtime ou polyfills
Além de desempenho, a flexibilidade do ecossistema também importa
Ter de gerenciar glue code JS manualmente ou depender de ferramentas de geração automática parece um grande retrocesso
Foi impressionante o experimento com Dodrio ter obtido 45% menos overhead ao omitir o glue
Ainda assim, fiquei curioso sobre como funciona o gerenciamento de memória quando o WebAssembly Component Model interage diretamente com Web APIs
Queria saber se a proposta de Wasm GC é usada para manter referências ao DOM, ou se ainda depende do GC do JS
Espero ver o Wasm realmente se firmar como um cidadão de primeira classe
Mas atualmente o IPC ainda é ineficiente, e acho que seria preciso algo como transferência em unidades de páginas de memória
Permitir que qualquer um execute programas complexos no meu computador sempre foi uma ideia de segurança insana, mas foi exatamente isso que fizemos
Graças ao JS, passamos 20 anos convivendo com inúmeros bugs de segurança em navegadores, mas agora já existem princípios de projeto e medidas de mitigação estabelecidos
E agora é ao mesmo tempo irônico e bonito querer substituir isso por outro paradigma de execução arriscado
Sistemas operacionais móveis fazem isso muito melhor do que desktops
São projetados com foco em engenheiros e não têm um fluxo de trabalho padrão amigável para autores
Ainda assim, é bom saber que ainda existem pessoas preocupadas com esse tipo de problema
Parece engineering excessivo para mapear as APIs do DOM em 1:1 só para obter processamento de strings 2x mais rápido
Em APIs como WebGL2, WebGPU e WebAudio, o custo do shim em JS já é mínimo
O verdadeiro problema está em coisas como cópia de buffer da GPU, e o component model não ajuda nisso
Gostaria de ver um benchmark testando dezenas de milhares de draw calls em WebGL2 ou WebGPU
Além do desempenho, melhorar a experiência do desenvolvedor (DX) também é importante
Hoje é difícil demais começar, e todo mundo precisa virar especialista para conseguir aproveitar os benefícios
Se conseguir competir com a eficiência de apps nativos, isso seria uma mudança visionária para o futuro da web
Na era dos agentes de código, a melhoria de DX de que eles falam já não importa mais