No
último artigo no WebAssembly, fiz a seguinte declaração:
Alguns comparam o WebAssembly com os applets Java. Em certo sentido, eles estão certos, mas, por outro lado, estão muito enganados. De alguma forma, escreverei um artigo sobre as diferenças, mas por enquanto vamos falar sobre as semelhanças. De certa forma, o WebAssembly é uma maneira diferente de realizar o objetivo da JVM: é uma máquina virtual comum para software de plataforma cruzada.
Muitas pessoas manifestaram interesse neste tópico, então vamos dar uma olhada mais de perto! Neste artigo, comparamos o WebAssembly com três tecnologias: Flash, applets Java e um
pouco com o PNaCL. O artigo também se concentra em usá-lo na
Web , embora anteriormente analisássemos opções para usar o WebAssembly offline. Mas falaremos sobre
essa comparação mais tarde. Finalmente, este artigo é semelhante a comer tapas [lanche espanhol de muitos ingredientes diferentes - aprox. por.], aqui estão algumas seções pequenas. Parece-me que é um pouco curto, mas ao mesmo tempo estou tentando blogar e, se continuar a expandi-lo, levará uma eternidade, então, desculpe-me.
Eu acho que uma comparação com os applets Flash e Java é bastante
natural quando você se deparar com essa descrição do WebAssembly:
O WebAssembly (Wasm para abreviar) é um formato de instrução binário para uma máquina virtual empilhada. O Wasm foi desenvolvido como uma versão portátil da compilação de linguagens de alto nível, como C, C ++ e Rust, que permite implantar aplicativos de cliente e servidor na Internet.
Isso é um pouco como a tecnologia do passado. É lógico comparar como eles estão conectados e sugerir pequenas diferenças entre eles. Mas o WebAssembly é significativamente diferente por vários motivos.
Wasm derrotado
A primeira razão pela qual o WebAssembly é diferente é porque acabou tendo sucesso, enquanto as tecnologias anteriores não. Quero dizer vitória em um sentido específico. Se você comparar o número de aplicativos Flash e o número de aplicativos WebAssembly, o Wasm provavelmente perderá. Os adeptos do WebAssembly terão que trabalhar duro para distribuir esta plataforma.
Quando falo sobre a vitória do WebAssembly, quero dizer que ele se tornou parte da plataforma da web. Flash, applets Java e PNaCL funcionaram por meio de plugins. De certa forma, eles estavam
fora do ecossistema da web. Eles nunca foram incluídos no padrão, e isso é muito importante.
Em certo sentido, tal explicação é suficiente. Mas apenas apontar um fato não significa explicar suas
causas . O restante deste artigo tentará descobrir por
que isso aconteceu: por que o WebAssembly conseguiu o que outras tecnologias não podiam fazer. Aqui,
muitas razões estão relacionadas entre si, mas estou tentando dividi-las razoavelmente em pontos separados.
Outras tecnologias não se encaixavam na plataforma
Você se lembra disso?
Ou é?
Que tal isso?
Um applet criado nessas tecnologias não é realmente um
aplicativo da web . Você tem uma página da Web com um pedaço recortado e seu applet funcionou nesse quadro. Você perde todas as vantagens de outras tecnologias da web: nem HTML, nem CSS, nem a capacidade de integrar-se à web. Essas plataformas não interagem com o restante da plataforma no navegador. Bem,
tecnicamente eles podem , mas na prática, essas tecnologias foram usadas de maneira diferente.
Como a web suporta um ecossistema que não se integra a ela? Isso nunca vai acontecer. E os usuários finalmente o rejeitaram resolutamente. Além dos jogos, os usuários
odiavam o Flash, e os applets Java eram pesados e lentos. Essas tecnologias não estão entrincheiradas na plataforma da web.
O WebAssembly, por outro lado, está muito mais próximo do JavaScript. De fato, o Wasm não tira parte da tela de você. Ele não cria seu próprio mundinho fechado. Agora, usando JavaScript, e
no futuro por conta própria , ele é capaz de interagir com o ambiente. Ele apenas ... se encaixa nisso.
Outra tecnologia de propriedade de empresas
Java era de propriedade da Sun Microsystems, o Flash era de propriedade da Adobe. Por que isso é importante?
A influência corporativa na Internet é um tópico complexo.
Em geral, a web opera em um modelo de pseudo-consenso. Java e Flash, por outro lado, eram controlados por suas respectivas empresas. Eles têm uma forte motivação para obter lucro, não para melhorar a Internet. E isso levou parcialmente à situação mencionada acima: essas empresas não se preocupavam em se integrar adequadamente com o restante da plataforma. Por que eles precisam disso? É muito melhor para as empresas bloquear sua plataforma e abandonar completamente o resto da Internet. A motivação é completamente distorcida.
O WebAssembly é uma iniciativa conjunta da Mozilla, Google, Apple, Microsoft e outros. Ele não promove a plataforma específica de alguém, mas representa os interesses comuns de uma ampla gama de partes interessadas, corporativas e individuais.
O WebAssembly seguiu o processo da web
A afiliação corporativa
também significa que essas tecnologias nunca seguiram o processo que usamos para padronizar a web. O processo de adoção de padrões da Web está bem estabelecido, mas essas tecnologias eram muito grandes e funcionavam de maneira um pouco diferente. Por outro lado, o WebAssembly seguiu o procedimento padrão adotado para tecnologias da web.
O Asm.js foi criado como prova de que podemos fazer coisas impressionantes com a web. Sua execução acabou sendo de alta qualidade e demonstrou as capacidades da tecnologia, embora não haja nada de fantástico por lá. O principal trunfo do
asm.js era que era apenas código JavaScript: é totalmente compatível com o ecossistema existente. "Não quebre a Internet" é uma regra muito, muito importante para desenvolvedores de navegadores.
O WebAssembly foi uma versão aprimorada do
asm.js Após encontrar algum consenso sobre o
asm.js todos se reuniram para tornar o WebAssembly uma realidade. Como esse não é apenas o JavaScript, ele deveria ter passado por todo o processo de implementação nos navegadores e passou por ele. Esta é agora a especificação W3C, que
está em conformidade com os padrões da Web, mas não os contradiz.
Consequência: outras tecnologias eram muito grandes e instáveis
Outro motivo pelo qual Wasm teve sucesso: é pequeno. Wasm adota a abordagem de outras tecnologias da Web: comece pequeno e cresça nessa base. Mantenha compatível com versões anteriores. As tecnologias passadas também não seguiram essa convenção social específica. Um tempo de execução específico foi carregado para os applets Flash e Java, portanto, a compatibilidade não era necessária. O PNaCl é construído sobre o código IR LLVM completamente instável. Eles iriam torná-lo um subconjunto estável, mas se o LLVM mudasse, haveria uma discrepância, o que não é muito bom.
Essas tecnologias também são muito pesadas para se ter esperança de estabilização. Você pode imaginar que quatro fabricantes de navegadores definem completamente as especificações da JVM e depois aceitam essa semântica para sempre? Para todo o ActionScript, que por si só é uma versão semelhante, mas diferente do ECMAScript? Para tudo LLVM-IR?
As grandes tecnologias representam um risco inaceitável para a situação. Este é um acordo do tipo tudo ou nada, e aqui está uma aposta segura do "nada". O WebAssembly, por outro lado, quase não faz nada. Isso é principalmente matemática e uma chamada de JavaScript. Ou seja, é
muito mais fácil concordar aqui.
Corolário: outras tecnologias exigem uma máquina virtual separada
Neste artigo, não mencionei Dart, mas também se encaixa aqui. A frase "Vamos colocar a JVM em cada navegador", o principal problema é que o navegador
já possui um tempo de execução JavaScript. Mesmo um tempo de execução é bastante difícil de manter, sem mencionar dois. E como você os integra?
O WebAssembly, por outro lado, foi projetado como uma pequena extensão para as máquinas virtuais JavaScript existentes. Embora você
possa implementar sua própria máquina virtual WebAssembly - isso geralmente é feito com o WebAssembly offline, mas para navegadores, os custos de manutenção são muito, muito mais baixos.
Outras tecnologias são muito específicas.
O WebAssembly é fundamentalmente independente do idioma. Os applets Flash e Java foram projetados principalmente para executar o ActionScript e Java. Eles estão profundamente ligados à sua semântica relativa. Até o PNaCl sofre, até certo ponto, com isso: o LLVM é realmente adequado para idiomas do tipo C, embora não exatamente na mesma extensão.
Queremos realmente escolher um idioma para toda a Internet? Já temos JavaScript. Já imaginou uma terceira língua? Quarto? Uma abordagem independente é muito melhor a longo prazo.
Wasm tem uma abordagem estrita à segurança
Applets Java e Flash foram um verdadeiro
pesadelo de segurança. Mesmo se tentassem protegê-los, na realidade surgiam problemas constantemente.
Por outro lado, o WebAssembly novamente recebeu bônus da VM JavaScript: todos os esforços para isolar sua sandbox também se aplicam ao Wasm. Aqui, algumas funções do montador usual estão ausentes, o que pode levar a vulnerabilidades, como destruição de pilha. Wasm trabalha com segurança na memória, o que é muito importante!
Além disso, o WebAssembly foi originalmente projetado com a idéia de
validação em mente : é totalmente digitado e os programas podem ser verificados sem a execução de código. As especificações incluem instruções sobre como conduzir essa validação. Isso é muito útil!
Conclusão
Quero dizer o seguinte sobre este artigo: ele foi escrito do ponto de vista do
desenvolvedor . Mas os desenvolvedores são importantes porque controlam a web. A tecnologia deve ser consistente com seus objetivos - isso é tão importante quanto a conveniência para os usuários finais. Em um artigo futuro, tentarei analisar os problemas do ponto de vista dos usuários. Tem que escrever muito!
Para resumir:
- Outras tecnologias não foram integradas à plataforma da Web, e isso foi prejudicado por interesses comerciais.
- Outras tecnologias exigiam muito: muitas tiveram que sacrificar na implementação.
- Wasm tem realmente um bom isolamento e validação de sandbox, que outros simplesmente não tinham.