WebAssembly

WebAssembly (às vezes abreviado como Wasm) é um padrão aberto que define um formato de código binário portátil para programas executáveis e uma linguagem assembly textual correspondente, bem como interfaces para facilitar as interações entre esses programas e seu ambiente hospedeiro.^[2][3][4][5] O principal objetivo do WebAssembly é habilitar aplicativos de alto desempenho em páginas web, mas o formato é projetado para ser executado e integrado em outros ambientes também, incluindo os autônomos.^[6][7][8]

WebAssembly
Paradigma	Máquina de pilha estruturada[1]
Surgido em	março de 2017 (8 anos)
Criado por	W3C Mozilla Microsoft Google Apple
Influenciada por	asm.js PNaCl
Plataforma	Multiplataforma
Licença	Licença Apache 2.0
Extensão do arquivo	.wat (formato texto) .wasm (formato binário)
Página oficial	webassembly.org

WebAssembly (ou seja, WebAssembly Core Specification (então a versão 1.0, 1.1 está em rascunho^[9]) e WebAssembly JavaScript Interface^[10]) tornou-se uma recomendação do World Wide Web Consortium em 5 de dezembro de 2019,^[11] junto com HTML, CSS e JavaScript.^[12]

WebAssembly pode suportar (pelo menos em teoria) qualquer linguagem (por exemplo, compilada ou interpretada) em qualquer sistema operacional (com a ajuda de ferramentas apropriadas),^[13] e na prática todas as linguagens mais populares já têm pelo menos algum nível de suporte.

O Emscripten SDK pode compilar qualquer código-fonte escrito em linguagens suportadas por LLVM (como C, C++ ou Rust, entre outras) em um arquivo binário que é executado na mesma sandbox como código JavaScript.^{[nota 1]} Emscripten fornece ligações para várias interfaces de ambiente comumente usadas, como WebGL. Não há acesso direto ao Document Object Model (DOM); entretanto, é possível criar funções proxy para isso, por exemplo através de stdweb,^[18] web_sys,^[19] e js_sys^[20] ao usar a linguagem Rust.

As implementações do WebAssembly geralmente usam compilação ahead-of-time (AOT) ou just-in-time (JIT), mas também podem usar um interpretador. Embora as implementações atualmente mais conhecidas possam ser em navegadores web, também existem implementações sem navegador para uso geral, incluindo WebAssembly Micro Runtime,^[21] um projeto da Bytecode Alliance (com o subprojeto iwasm code VM suportando "interpretador, compilação ahead-of-time (AoT) e compilação Just-in-Time (JIT)"^[22]), Wasmtime,^[23] e Wasmer.^[13]

O World Wide Web Consortium (W3C) mantém o padrão com contribuições da Mozilla, Microsoft, Google, Apple, Fastly, Intel, e Red Hat.^[24][21]

História

O WebAssembly foi anunciado pela primeira vez em 2015,^[25] e a primeira demonstração foi a execução do Angry Bots do Unity no Firefox,^[26] Google Chrome,^[27] e Microsoft Edge.^[28] As tecnologias precursoras foram asm.js da Mozilla e Google Native Client,^[29][30] e a implementação inicial foi baseada no conjunto de recursos do asm.js.^[31] A tecnologia asm.js já fornece velocidades de execução de código quase nativas^[32] e pode ser considerada uma alternativa viável para navegadores que não oferecem suporte ao WebAssembly ou que o desativaram por motivos de segurança.

Em março de 2017, o projeto do produto viável mínimo (MVP) foi declarado concluído e a fase de prévia encerrada.^[33] No final de setembro de 2017^[update], o Safari 11 foi lançado com suporte. Em fevereiro de 2018, o Grupo de Trabalho WebAssembly publicou três rascunhos de trabalho público para a Especificação Central, Interface JavaScript, e API Web.^{[34][35][36][37]}

Implementações

Embora o WebAssembly tenha sido projetado inicialmente para permitir uma velocidade de execução de código quase nativa no navegador da web, ele foi considerado valioso fora disso, em contextos mais generalizados.^[38][39] Uma vez que os ambientes de tempo de execução (RE) do WebAssembly são máquinas de pilha virtual de baixo nível (semelhantes a JVM ou Flash VM) que podem ser incorporadas em aplicativos hospedeiros, alguns deles se tornaram ambientes de tempo de execução autônomos como Wasmtime e Wasmer.^[8][13]

Navegadores web

Em novembro de 2017, a Mozilla declarou o suporte "em todos os principais navegadores",^[40] depois que WebAssembly foi habilitado por padrão no Edge 16.^[41] O suporte inclui navegadores móveis para iOS e Android. Em março de 2021^[update], 93% dos navegadores instalados (93% dos navegadores de desktop e 94% dos navegadores móveis) suportam WebAssembly.^[42] Mas para navegadores mais antigos, Wasm pode ser compilado em asm.js por um polyfill JavaScript.^[43]

Compiladores

Como os executáveis do WebAssembly são pré-compilados, é possível usar uma variedade de linguagens de programação para criá-los.^[44] Isso é conseguido através da compilação direta no Wasm, ou através da implementação das máquinas virtuais correspondentes no Wasm. Há cerca de 40 linguagens de programação conhecidas que suportam Wasm como um alvo de compilação.^[45]

Emscripten compila C e C++ para Wasm^[33] usando Binaryen e LLVM como backend.^[46]

A partir da versão 8, um Clang autônomo pode compilar C e C++ para Wasm.^[47]

Seu objetivo inicial é oferecer suporte à compilação de C e C++,^[48] embora o suporte para outras linguagens de fonte como Rust, linguagens .NET^[49][50][45] e AssemblyScript^[51] (similar a TypeScript) também esteja surgindo. Após o lançamento do MVP, existem planos para suportar multithreading e coleta de lixo^[52][53], o que tornaria o WebAssembly um alvo de compilação para linguagens de programação coletadas como C# (suportado via Blazor), F# (suportado via Bolero^[54] com ajuda de Blazor), Python e até JavaScript onde a velocidade de compilação just-in-time do navegador é considerada muito lenta. Várias outras linguagens têm algum suporte, incluindo Python,^[55] Java,^[56] Julia,^[57][58][59] Zig,^[60] e Ruby,^[61] bem como Go.^[62]

Limitações

1. Em geral, WebAssembly não permite interação direta com o DOM. Toda interação deve fluir por meio da interoperabilidade JavaScript.
2. Multithreading (embora haja planos para resolver isso).
3. Coleta de lixo (embora haja planos para resolver isso).
4. Considerações de segurança (discutidas abaixo)

O WebAssembly é compatível com desktops e dispositivos móveis, mas no último, na prática (para alocações de memória não pequenas, como com o motor de jogo Unity) existem "limitações graves que tornam muitos aplicativos inviáveis para serem implantados de forma confiável em navegadores móveis [..] Atualmente, alocar mais de ~300 MB de memória não é confiável no Chrome no Android sem recorrer a soluções alternativas específicas do Chrome, nem no Safari no iOS."^[63]

Todos os navegadores web principais permitem o WebAssembly se Content-Security-Policy não for especificado, ou se "unsafe-eval" é usado, mas, caso contrário, os principais navegadores web se comportam de maneira diferente.^[64] Na prática, o WebAssembly não pode ser usado no Chrome sem "unsafe-eval",^[65][66] enquanto uma solução alternativa baseada em worker thread está disponível.^[66]

Considerações de segurança

Em junho de 2018, um pesquisador de segurança apresentou a possibilidade de usar o WebAssembly para contornar as mitigações do navegador para as vulnerabilidades de segurança Spectre e Meltdown assim que o suporte para threads com memória compartilhada for adicionado. Devido a essa preocupação, os desenvolvedores do WebAssembly suspenderam o desenvolvimento do recurso.^[67][68][69] No entanto, a fim de explorar essas futuras extensões de linguagem, o Google Chrome adicionou suporte experimental para a proposta de thread WebAssembly em outubro de 2018.^[70]

O WebAssembly foi criticado por permitir maior facilidade de ocultar as evidências para criadores de malware, golpistas e atacantes de phishing; O WebAssembly só está presente na máquina do usuário em sua forma compilada, o que "torna a detecção [do malware] difícil".^[71] A velocidade e capacidade de ocultação do WebAssembly levaram ao seu uso na criptomineração oculta no dispositivo do visitante do site.^[71][72][67] Coinhive, um serviço extinto que facilita a mineração de criptomoedas nos navegadores dos visitantes do site, afirma que seu "minerador usa WebAssembly e executa com cerca de 65% do desempenho de um minerador nativo."^[67] Um estudo feito em junho de 2019 pela Universidade de Tecnologia de Braunschweig (Technische Universität Braunschweig) analisou o uso do WebAssembly nos 1 milhão de websites mais acessados do mundo na lista da Alexa e descobriu que o uso predominante era para criptomineração maliciosa e que o malware era responsável por mais da metade dos sites que usam o WebAssembly estudados.^[73][74] Um estudo feito em abril de 2021 pela Universidade de Estugarda (Universität Stuttgart) descobriu que, desde então, a criptomineração foi marginalizada, caindo para menos de 1% de todos os módulos WebAssembly coletados de uma ampla gama de fontes, incluindo também os 1 milhão de websites mais acessados do mundo na lista da Alexa.^[75]

A capacidade de ofuscar com eficácia grandes quantidades de código também pode ser usada para desativar o bloqueio de anúncios e ferramentas de privacidade que impedem o rastreamento da web, como o Privacy Badger.

Como o WebAssembly só oferece suporte a fluxo de controle estruturado, é adequado para técnicas de verificação de segurança, incluindo execução simbólica. Os esforços atuais nessa direção incluem o mecanismo de execução simbólica Manticore.^[76]

WASI

WebAssembly System Interface (WASI) é uma interface simples (ABI e API) projetada pela Mozilla para ser portável para qualquer plataforma.^[77] Ele fornece recursos tipo POSIX, como E/S de arquivo restrito pela segurança baseada em capacidade.^[78][79] Existem também algumas outras ABI/APIs propostas.^[80][81]

WASI é influenciado por CloudABI e Capsicum.

Solomon Hykes, um cofundador do Docker, escreveu em 2019: "Se WASM+WASI existisse em 2008, não precisaríamos criar o Docker. Isso é o quão importante é. WebAssembly no servidor é o futuro da computação."^[82] O Wasmer, lançado na versão 1.0, fornece "contêinerização de software, criamos binários universais que funcionam em qualquer lugar sem modificação, incluindo sistemas operacionais como Linux, macOS, Windows e navegadores web. O Wasm automaticamente coloca os aplicativos em sandbox por padrão para execução segura".^[82]

Especificação

Ambiente hospedeiro

O padrão geral fornece especificações básicas para a API JavaScript e detalhes sobre incorporação.^[4]

Máquina virtual

O código Wasm (código binário, ou seja, bytecode) deve ser executado em uma máquina virtual de pilha (VM) portátil.^[83] A VM foi projetada para ser mais rápida de analisar e executar do que o JavaScript e ter uma representação de código compacta.^[48] Uma funcionalidade externa (como chamadas de sistema) que pode ser esperada pelo código binário Wasm não é estipulada pelo padrão. Em vez disso, fornece uma maneira de fornecer interface via módulos pelo ambiente hospedeiro em que a implementação da VM é executada.^[84][8]

Programa Wasm

Um programa Wasm é projetado para ser um módulo separado contendo coleções de vários valores definidos pelo Wasm e definições de tipo de programa. Eles são expressos em formato binário ou textual (veja abaixo), ambos com uma estrutura comum.^[85]

Conjunto de instruções

O padrão central para o formato binário de um programa Wasm define uma arquitetura do conjunto de instruções (ISA) que consiste em codificações binárias específicas de tipos de operações que são executadas pela VM (sem especificar como exatamente elas devem ser executadas).^[86] A lista de instruções inclui instruções de carregamento/armazenamento de memória padrão, numéricas, paramétricas, controle de fluxo e instruções de variáveis específicas do Wasm.^[87]

O número de opcodes usados no padrão original (MVP) era um pouco menos do que 200 dos 256 opcodes possíveis. As versões subsequentes do WebAssembly aumentaram o número de opcodes um pouco acima de 200. A proposta WebAssembly SIMD (para processamento paralelo) apresenta um prefixo de opcode alternativo (0xfd) para SIMD de 128 bits. A concatenação do prefixo SIMD, mais um opcode válido após o prefixo SIMD, forma um opcode SIMD. Os opcodes SIMD trazem 236 instruções adicionais para a capacidade SIMD do "produto viável mínimo" (MVP) (para um total de cerca de 436 instruções).^[88][89] Essas instruções, os "opcodes finalizados"^[90] são implementados no V8 do Google (no Google Chrome) e no mecanismo correspondente no Mozilla Firefox (mas não ativados em versões estáveis dos navegadores web),^[91] e também há proposta adicional de instruções para "pós SIMD MVP" posterior, e também há uma proposta "relaxed-simd" separada em discussão.^[92]

Esses opcodes SIMD também são portáveis e traduzem para conjuntos de instruções nativos como x64 e ARM. Em contraste, nem JVM do Java (nem CIL) suportam SIMD, no nível de opcode delas (enquanto ambos fornecem paralelo prático algum aumento de velocidade de SIMD), ou seja, no padrão, mas há uma extensão disponível adicionando intrínsecos para SIMD x64,^[93] que não seria portável, ou seja, não utilizável em ARM ou smartphones. Os smartphones podem oferecer suporte a SIMD chamando o código assembly com SIMD, e C# tem suporte semelhante.

Representação de código

Em março de 2017, o WebAssembly Community Group chegou a um consenso sobre o formato binário inicial (MVP), API JavaScript e interpretador de referência.^[94] Ele define um formato binário do WebAssembly (.wasm), que não é projetado para ser usado por humanos, bem como um formato de texto WebAssembly legível (.wat) que se assemelha a um cruzamento entre expressões S e linguagens de montagem tradicionais.

A tabela abaixo mostra um exemplo de uma função fatorial escrita em C e seu código WebAssembly correspondente após a compilação, mostrado em formato de texto .wat (uma representação textual legível de WebAssembly) e em formato binário .wasm (o bytecode bruto, expresso abaixo em hexadecimal), que é executado por um navegador web ou ambiente de tempo de execução que suporta WebAssembly.

Código fonte em C e WebAssembly correspondente

Código fonte em C	Formato de texto WebAssembly .wat	Formato binário WebAssembly .wasm
int factorial(int n) { if (n == 0) return 1; else return n * factorial(n-1); }	(func (param i64) (result i64) local.get 0 i64.eqz if (result i64) i64.const 1 else local.get 0 local.get 0 i64.const 1 i64.sub call 0 i64.mul end)	00 61 73 6D 01 00 00 00 01 00 01 60 01 73 01 73 06 03 00 01 00 02 0A 00 01 00 00 20 00 50 04 7E 42 01 05 20 00 20 00 42 01 7D 10 00 7E 0B 0B 15 17

Todas as constantes inteiras são codificadas usando uma codificação LEB128 de tamanho variável e eficiente em espaço.^[95]

O formato de texto WebAssembly é escrito mais canonicamente em um formato dobrado usando expressões S. Para instruções e expressões, este formato é puramente açúcar sintático e não tem diferenças comportamentais com o formato linear.^[96] Por meio do wasm2wat, o código acima se decompila para:

(module
  (type $t0 (func (param i64) (result i64)))
  (func $f0 (type $t0) (param $p0 i64) (result i64)
    (if $I0 (result i64) ; $I0 is an unused label name
      (i64.eqz
        (local.get $p0)) ; the name $p0 is the same as 0 here
      (then
        (i64.const 1))
      (else
        (i64.mul
          (local.get $p0)
          (call $f0      ; the name $f0 is the same as 0 here
            (i64.sub
              (local.get $p0)
              (i64.const 1))))))))

Observe que um módulo é gerado implicitamente pelo compilador. A função é, na verdade, referenciada por uma entrada da tabela de tipos no binário, portanto, uma seção de tipos e o tipo emitido pelo descompilador.^[97] O compilador e o descompilador podem ser acessados online.^[98]

Bibliografia

• Haas, Andreas; Rossberg, Andreas; Schuff, Derek L.; Titzer, Ben L.; Gohman, Dan; Wagner, Luke; Zakai, Alon; Bastien, JF; Holman, Michael (junho de 2017). «Bringing the web up to speed with WebAssembly». Association for Computing Machinery. Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation: 185–200. ISBN 9781450349888. doi:10.1145/3062341.3062363
• Watt, Conrad (2018). «Mechanising and Verifying the WebAssembly Specification» (PDF). ACM. ACM SIGPLAN International Conference on Certified Programs and Proofs. 7: 53–65. ISBN 9781450355865. doi:10.1145/3167082

Notas

1. De acordo com a documentação oficial, o Emscripten SDK pode ser usado para criar arquivos .wasm que depois podem ser executados em um navegador web.^[14][15][16] Mesmo que o Emscripten possa consumir várias linguagens ao usar o Clang, alguns problemas podem surgir.^[17]

Referências

1. «WebAssembly/design/Semantics.md». GitHub (em inglês). Consultado em 23 de fevereiro de 2021. WebAssembly code can be considered a structured stack machine; a machine where most computations use a stack of values, but control flow is expressed in structured constructs such as blocks, ifs, and loops. In practice, implementations need not maintain an actual value stack, nor actual data structures for control; they need only behave as if they did so.
2. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 18 de junho de 2019. WebAssembly is an open standard...
3. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 18 de junho de 2019. WebAssembly is a ... code format
4. «Conventions — WebAssembly 1.0». webassembly.github.io. Consultado em 17 de maio de 2019. WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure.
5. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 18 de junho de 2019. ... this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.
6. «Introduction — WebAssembly 1.1». webassembly.github.io. Consultado em 19 de fevereiro de 2021. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.
7. Haas, Andreas; Rossberg, Andreas; Schuff, Derek L.; Titzer, Ben L.; Holman, Michael; Gohman, Dan; Wagner, Luke; Zakai, Alon; Bastien, JF (14 de junho de 2017). «Bringing the Web Up to Speed with WebAssembly». SIGPLAN Notices. 52 (6): 185–200. ISSN 0362-1340. doi:10.1145/3140587.3062363. While the Web is the primary motivation for WebAssembly, nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.
8. «Outside the web: standalone WebAssembly binaries using Emscripten · V8». v8.dev. Consultado em 28 de julho de 2020
9. «WebAssembly Specification — WebAssembly 1.1». webassembly.github.io. Consultado em 22 de março de 2021
10. «WebAssembly JavaScript Interface». www.w3.org. Consultado em 24 de junho de 2020
11. World Wide Web Consortium. «WebAssembly Core Specification». World Wide Web Consortium (W3). Consultado em 9 de dezembro de 2019
12. Couriol, Bruno. «WebAssembly 1.0 Becomes a W3C Recommendation and the Fourth Language to Run Natively in Browsers». infoq.com. Consultado em 9 de dezembro de 2019
13. «Wasmer - The Universal WebAssembly Runtime». wasmer.io. Consultado em 19 de fevereiro de 2021. Compile everything to WebAssembly. Run it on any OS or embed it into other languages.
14. «Developer's Guide - WebAssembly». webassembly.org. Consultado em 10 de junho de 2019
15. «Compiling a New C/C++ Module to WebAssembly». MDN Web Docs (em inglês). Consultado em 10 de junho de 2019
16. «Building to WebAssembly — Emscripten 1.38.33 documentation». emscripten.org. Consultado em 10 de junho de 2019
17. «Emscripting a C library to Wasm | Web». Google Developers (em inglês). Consultado em 10 de junho de 2019
18. «stdweb - Rust». docs.rs. Consultado em 5 de junho de 2019. The goal of this crate is to provide Rust bindings to the Web APIs and to allow a high degree of interoperability between Rust and JavaScript.
19. «web_sys - Rust». docs.rs. Consultado em 5 de junho de 2019. Raw API bindings for Web APIs. This is a procedurally generated crate from browser WebIDL which provides a binding to all APIs that browser provide on the web.
20. «js_sys - Rust». docs.rs. Consultado em 5 de junho de 2019. Bindings to JavaScript's standard, built-in objects, including their methods and properties.
21. «New Bytecode Alliance Brings the Security, Ubiquity, and Interoperability of the Web to the World of Pervasive Computing». Mozilla (em inglês). 12 de novembro de 2019. Consultado em 27 de maio de 2019
22. «bytecodealliance/wasm-micro-runtime». Bytecode Alliance. 19 de fevereiro de 2021. Consultado em 19 de fevereiro de 2021
23. «Wasmtime — a small and efficient runtime for WebAssembly & WASI». wasmtime.dev. Consultado em 18 de dezembro de 2020
24. Bright, Peter (18 de junho de 2015). «The Web is getting its bytecode: WebAssembly». Ars Technica. Condé Nast
25. «Launch bug». GitHub / WebAssembly / design. 11 de junho de 2015
26. Wagner, Luke (14 de março de 2016). «A WebAssembly Milestone: Experimental Support in Multiple Browsers». Mozilla Hacks
27. Thompson, Seth (15 de março de 2016). «Experimental support for WebAssembly in V8». V8 Blog
28. Zhu, Limin (15 de março de 2016). «Previewing WebAssembly experiments in Microsoft Edge». Microsoft Edge dev blog
29. Lardinois, Frederic (17 de junho de 2015). «Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web». TechCrunch (em inglês). Consultado em 24 de dezembro de 2017
30. Avram, Abel (31 de maio de 2017). «Google Is to Remove Support for PNaCl». InfoQ. Consultado em 22 de dezembro de 2017
31. «WebAssembly: a binary format for the web». ②ality – JavaScript and more. 18 de junho de 2015
32. «Staring at the Sun: Dalvik vs. ASM.js vs. Native». blog.mozilla.org. Consultado em 7 de dezembro de 2019. Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.
33. Krill, Paul (6 de março de 2017). «WebAssembly is now ready for browsers to use». InfoWorld (em inglês). Consultado em 23 de dezembro de 2017
34. «WebAssembly First Public Working Drafts». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
35. «WebAssembly Core Specification». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
36. «WebAssembly JavaScript Interface». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
37. «WebAssembly Web API». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
38. «Non-Web Embeddings». WebAssembly. Consultado em 15 de maio de 2019
39. «Non-Web Embeddings». GitHub / WebAssembly. Consultado em 15 de maio de 2019
40. «WebAssembly support now shipping in all major browsers». The Mozilla Blog (em inglês). Consultado em 21 de novembro de 2017
41. «Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16». Microsoft Edge Dev Blog (em inglês). 31 de outubro de 2017. Consultado em 21 de novembro de 2017
42. «WebAssembly». Can I use. Consultado em 22 de março de 2020
43. Bright, Peter (18 de junho de 2015). «The Web is getting its bytecode: WebAssembly». Ars Technica (em inglês). Consultado em 23 de dezembro de 2017
44. Ball, Kevin (26 de junho de 2018). «How WebAssembly is Accelerating the Future of Web Development». Consultado em 22 de outubro de 2018. Cópia arquivada em 12 de fevereiro de 2019
45. «Awesome WebAssembly Languages». 26 de junho de 2018. Consultado em 12 de fevereiro de 2019. Cópia arquivada em 12 de fevereiro de 2019
46. Alon Zakai [@kripken] (21 de outubro de 2019). «Emscripten has switched to the upstream LLVM wasm backend by default! / Details:https://groups.google.com/forum/#!topic/emscripten-discuss/NpxVAOirSl4 …» (Tweet). Consultado em 22 de outubro de 2019 – via Twitter
47. «LLVM 8.0.0 Release Notes — LLVM 8 documentation». releases.llvm.org. Consultado em 22 de outubro de 2019
48. «WebAssembly High-Level Goals». GitHub / WebAssembly / design. 11 de dezembro de 2015
49. Krill, Paul (29 de novembro de 2017). «Direct WebAssembly compilation comes to Rust language». InfoWorld (em inglês). Consultado em 24 de dezembro de 2017
50. «Frequently asked questions (FAQ) about Blazor». blazor.net. Consultado em 18 de junho de 2018
51. «AssemblyScript/assemblyscript». The AssemblyScript Project. 9 de setembro de 2020. Consultado em 9 de setembro de 2020
52. Krill, Paul (26 de outubro de 2017). «What's next for WebAssembly: GC, threads, debugging». TechWorld. Consultado em 24 de dezembro de 2017
53. «🛤 Garbage collection · Issue #16 · WebAssembly/proposals». GitHub (em inglês). Consultado em 25 de julho de 2019
54. «Bolero: F# in WebAssembly». fsbolero.io. Consultado em 25 de julho de 2019
55. «Pyodide: Bringing the scientific Python stack to the browser – Mozilla Hacks - the Web developer blog». Mozilla Hacks – the Web developer blog (em inglês). Consultado em 9 de setembro de 2020
56. «Mozilla tries to do Java as it should have been – with a WASI spec for all devices, computers, operating systems». www.theregister.com (em inglês). Consultado em 6 de outubro de 2020
57. «Julia in the Browser». nextjournal.com. Consultado em 9 de abril de 2019
58. «WebAssembly platform by tshort · Pull Request #2 · JuliaPackaging/Yggdrasil». GitHub (em inglês). Consultado em 9 de abril de 2019
59. Fischer, Keno (22 de julho de 2019). «GitHub - Keno/julia-wasm: Running julia on wasm.». Consultado em 25 de julho de 2019
60. «Documentation - The Zig Programming Language». ziglang.org
61. «MRuby in Your Browser». ruby.dj. Consultado em 25 de julho de 2019
62. «golang/go». GitHub (em inglês). Consultado em 19 de fevereiro de 2021
63. «Wasm needs a better memory management story · Issue #1397 · WebAssembly/design». GitHub (em inglês). Consultado em 15 de fevereiro de 2021
64. «WebAssembly/content-security-policy». GitHub (em inglês). Consultado em 17 de fevereiro de 2021
65. «948834 - chromium - An open-source project to help move the web forward. - Monorail». bugs.chromium.org. Consultado em 17 de fevereiro de 2021
66. «No way to use WebAssembly on Chrome without 'unsafe-eval' · Issue #7 · WebAssembly/content-security-policy». GitHub (em inglês). Consultado em 17 de fevereiro de 2021
67. Neumann, Robert; Toro, Abel (19 de abril de 2018). «In-browser mining: Coinhive and WebAssembly» (em inglês). Forcepoint. Consultado em 8 de junho de 2019
68. Cimpanu, Catalin (24 de junho de 2018). «Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless» (em inglês). Bleeping Computer. Consultado em 8 de junho de 2019
69. Sanders, James (25 de junho de 2018). «How opaque WebAssembly code could increase the risk of Spectre attacks online». Tech Republic (em inglês). Consultado em 9 de junho de 2019
70. R, Bhagyashree (30 de outubro de 2018). «Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications». Packt Pub. Consultado em 9 de junho de 2019
71. Lonkar, Aishwarya; Chandrayan, Siddhesh (outubro de 2018). «The dark side of WebAssembly». Virus Bulletin. Consultado em 8 de junho de 2019
72. Segura, Jérôme (29 de novembro de 2017). «Persistent drive-by cryptomining coming to a browser near you». Malwarebytes. Consultado em 8 de junho de 2019
73. «Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes». InfoQ. Consultado em 3 de novembro de 2019
74. Musch, Marius; Wressnegger, Christian; Johns, Martin; Rieck, Konrad (junho de 2019). «New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild». Detection of Intrusions and Malware, and Vulnerability Assessment (PDF). Col: Lecture Notes in Computer Science. 11543. [S.l.]: Detection of Intrusions and Malware, and Vulnerability Assessment. pp. 23–42. ISBN 978-3-030-22037-2. doi:10.1007/978-3-030-22038-9_2. Consultado em 4 de novembro de 2019. Arquivado do original (PDF) em 21 de outubro de 2019 — Slides (PDF)
75. Aaron Hilbig; Daniel Lehmann; Michael Pradel (abril de 2021). «An Empirical Study of Real-World WebAssembly Binaries: Security, Languages, Use Cases.» (PDF)
76. «Symbolically Executing WebAssembly in Manticore». 31 de janeiro de 2020. Consultado em 10 de fevereiro de 2020
77. «WebAssembly System Interface Repo». GitHub / WebAssembly. 10 de fevereiro de 2020
78. «Additional background on Capabilities». GitHub (em inglês). bytecodealliance
79. «Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog». Mozilla Hacks – the Web developer blog
80. «reference-sysroot Repo». GitHub / WebAssembly. 12 de janeiro de 2020
81. «wasm-c-api Repo». GitHub / WebAssembly. 3 de fevereiro de 2020
82. «The "Wasmer" WebAssembly Runtime is Generally Available». InfoQ (em inglês). Consultado em 19 de fevereiro de 2021
83. «Design Rationale». GitHub / WebAssembly / design. 1 de outubro de 2016
84. «Portability - WebAssembly». webassembly.org. Consultado em 28 de julho de 2020
85. «Conventions — WebAssembly 1.0». webassembly.github.io. Consultado em 12 de novembro de 2019
86. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 17 de maio de 2019
87. «Instructions — WebAssembly 1.0». webassembly.github.io. Consultado em 12 de novembro de 2019
88. Lively, Thomas (19 de fevereiro de 2021). «Final opcodes by tlively · Pull Request #452 · WebAssembly/simd · GitHub». Bytecode Alliance. Consultado em 12 de maio de 2021 – via GitHub
89. Delendik, Yury (19 de fevereiro de 2021). «File wasm-tools/expr.rs at b5c3d98e40590512a3b12470ef358d5c7b983b15 · bytecodealliance/wasm-tools · GitHub». Bytecode Alliance. Consultado em 12 de maio de 2021 – via GitHub
90. «Update interpreter and text with finalized opcodes by ngzhian · Pull Request #486 · WebAssembly/simd». GitHub (em inglês). Consultado em 14 de maio de 2021
91. «WebAssembly/simd». GitHub (em inglês). Consultado em 14 de maio de 2021
92. «WebAssembly/relaxed-simd». WebAssembly. 3 de maio de 2021. Consultado em 14 de maio de 2021
93. «How we made the JVM 40x faster». astojanov.github.io. Consultado em 17 de fevereiro de 2021. ...support for all 5912 Intel SIMD intrinsics from MMX to AVX-512.
94. «Roadmap». WebAssembly. Março de 2017
95. WebAssembly Community Group (janeiro de 2020). «WebAssembly Specification Release 1.0». Consultado em 13 de janeiro de 2020
96. «Folded instructions». GitHub / WebAssembly / spec
97. «Modules (Binary)». WebAssembly 1.0
98. «WebAssembly Binary Toolkit (wabt) demos». webassembly.github.io