Design: por que não java ou .net?

Também sou novo no WebAssembly. Mas acho que isso já foi perguntado várias vezes. Talvez devesse estar no FAQ.

Meu palpite é que é porque .net e jvm não são apenas bytecode, eles são uma máquina virtual com sua própria coleta de lixo, carregador de classes e reflexão. O WebAssembly é, na verdade, apenas uma plataforma de operações de baixo nível independente do navegador. Acho que você poderia executar uma JVM no WebAssembly, mas isso não daria o resultado que você gostaria de ter. Isso simplesmente adicionaria o tempo de inicialização do WebAssembly e o tempo de inicialização da JVM. E você teria duas pilhas diferentes de coleta de lixo. O do JavaScript e o da sua nova JVM. Acho que atualmente você está melhor com o GWT.

É mais correto pensar no Web Assembly como uma evolução do asm.js, em vez de uma tecnologia completamente nova. A única capacidade que ele realmente tem sobre asm.js são inteiros de 64 bits, que nem mesmo são necessários para a maioria dos programas. Esse escopo limitado permite que ele seja integrado com relativa facilidade aos mecanismos JavaScript existentes.

Um dos veteranos do projeto Web Assembly provavelmente terá uma resposta mais completa, e eu concordo que este seria um bom item de FAQ, pois é provável que surja com frequência quando o 1.0 for lançado.

Bytecodes Jvm e .Net são especializados para suas máquinas virtuais relevantes, cada um com suas próprias preocupações e espaços de problema que estão tentando resolver separadamente das máquinas virtuais executadas em navegadores da web. Adaptar uma segunda máquina virtual inteira para rodar em navegadores da web seria complicado para os usuários, e adaptar Jvm e .Net vm apis para rodar dentro de máquinas virtuais existentes seria difícil de implementar e inevitavelmente complicado para os usuários, e possivelmente mais sujeito a erros / bugs. a complexidade cresce. Web Assembly é projetado como um ISA mais simples que pode ser facilmente executado nas máquinas virtuais Javascript já existentes nos navegadores, com foco na otimização do tempo de transporte e do tempo de carregamento, um conjunto de requisitos existentes em bytecodes que não atendem adequadamente.

Eu tinha certeza que tínhamos algo sobre isso nos documentos FAQ ou Rationale. Nós não. Seria uma ótima adição.

@ kovalenko0 Se eu puder oferecer minha opinião. JVM e .net não se deram bem na web porque teriam adicionado uma superfície de ataque significativa e, portanto, uma carga significativa e também inchaço. Se, no futuro, eles pudessem ser executados dentro da sandbox do wasm, isso acrescentaria uma camada de proteção que poderia atenuar o fardo. Wasm por enquanto parece focado em uma linguagem de baixo nível próxima ao hardware, e esperançosamente em uma superfície de ataque muito menor para sua sandbox, e esperançosamente um bom alvo para código em geral. Houve algumas outras tentativas muito significativas em linguagens de baixo nível, como NaCL, mas na minha opinião isso falhou porque era muito baixo nível de implantação de código nativo cozido que exigia validação. Esperançosamente, Wasm é um nível um pouco mais alto com uma camada de tradução que dá um pouco mais de flexibilidade e permite redirecionamento para qualquer processador e também abre o caminho para validação mais geral e cozimento nessas deduções de validação em código otimizado.

@ kovalenko0 Oh, e fazer com que todos os fornecedores de navegadores da web concordassem em agrupar uma JVM e .net também pode ter sido uma barreira (eu esperava por razões como a superfície de ataque e inchaço, mas talvez por razões muito mais mesquinhas também) , então asm.js trabalhou com o que era um terreno comum. O Wasm pode permitir que as pessoas usem JVM ou .Net na web, mesmo sem acordo entre os fornecedores do navegador da web, e que as pessoas façam seus próprios julgamentos sobre a segurança e o inchaço.

Estou disposto a escrever uma adição ao FAQ combinando as respostas aqui, mas qual é o processo de contribuição para este projeto?

Certifique-se de que você se juntou ao grupo da comunidade e, em seguida, envie um PR para o
repo de design.

Na sexta-feira, 27 de janeiro de 2017 às 19h56, Ryan Lamansky [email protected]
escreveu:

Estou disposto a escrever uma adição ao FAQ combinando as respostas
aqui, mas qual é o processo de contribuição para este projeto?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WebAssembly/design/issues/960#issuecomment-275744408 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ALnq1BziU5qIZOBNq5fBYLfOjoeOkMIzks5rWj3SgaJpZM4LmzIH
.

Contribuindo com detalhes. Eles estão vinculados na página "nova PR" 😁

Eu estava planejando inicialmente adicionar uma seção abaixo do LLVM, mas visto que essa seção foi escrita em 2015, algumas partes estão desatualizadas. Por exemplo...

Acreditamos que, usando nossa experiência com o LLVM e projetando uma codificação IR e binária para nossos objetivos e requisitos, podemos fazer muito melhor do que adaptar um sistema projetado para outros fins.

... parece muito cauteloso, visto que a codificação binária WASM atual está funcionando perfeitamente nas visualizações do navegador.

Agora estou pensando em substituir a seção LLVM por uma discussão mais geral sobre os códigos de byte existentes (mencionando LLVM, Java e .NET como exemplos), redigida com muito mais confiança na abordagem adotada pela equipe WebAssembly.

Alguma objeção?

@Kardax o que fazer com a seção LLVM seria até @dschuff / @sunfishcode.

@kardax Talvez seja melhor não adicionar nada porque há muitos prós e contras em diferentes designs e ainda muitas melhorias que poderiam ser feitas no wasm. O Asm.js pode ter estado "funcionando perfeitamente" da sua perspectiva e, de certa forma, teve um desempenho melhor do que o wasm, portanto, é mais do que isso. Você pode querer explorar os tempos e desempenho de análise / decodificação e compilação.

@wllang ... do que você está falando? Eu nunca disse que o ASM.JS tem um desempenho melhor do que o WASM. Acho que você interpretou mal o que escrevi. Também discordo veementemente que há muitas melhorias a serem feitas na codificação binária atual do WASM para MVP; Eu diria que é cerca de 98% bom continuar como está, e eu poderia viver sem os últimos 2%.

@dschuff / @sunfishcode A longa discussão sobre o bitcode LLVM ainda é relevante? Acho que a viabilidade de uma codificação binária especializada foi totalmente comprovada, então poderíamos matar três coelhos com uma cajadada só abordando os formatos intermediários LLVM, Java e .NET em uma única seção.

@Kardax Desculpe, não tive a intenção de sugerir que você 'disse que o ASM.JS teve um desempenho melhor do que o WASM'. Mas, por exemplo, o Asm.js tem variáveis ​​de módulo constantes e elas podem ser incorporadas ao código compilado e isso é algo que o wasm não tem e que foi muito útil e obter um recurso semelhante no wasm requer código do usuário para reescrever o módulo.

Como um grupo poderia avaliar objetivamente uma afirmação de que wasm está dentro de 2% de 'bom para ir' (o que quer que isso signifique)? Nós sabemos qual é o melhor desempenho possível, o melhor tamanho codificado, a melhor velocidade de decodificação e compilação etc, o mais baixo decodificar-compilar o uso de recursos etc? Não queremos torná-lo pessoal, não que alguém saiba melhor, e mesmo responder a tal afirmação é muito difícil, precisamos conversar sobre ideias técnicas que podem ser avaliadas pelo mérito técnico.

A discussão do llvm do FAQ parece valiosa para mim, muitos pontos bons, e ainda muito relevantes e, pessoalmente, ainda estou explorando o espaço do design e considero essa lógica muito útil.

Ainda não temos implementações de decodificação e compilação de alto desempenho e espero que elas realmente ajudem a finalizar as decisões de design e vejo que o design pode seguir em várias direções diferentes. A codificação ainda tem informações de definição-último-uso muito incompletas (o empilhamento fornece algumas delas) que são necessárias para a alocação de registro e espero que o conjunto ativo seja necessário para implementar algoritmos de derramamento, e pode haver mais do que pode ser feito com loops, etc. Existem muitos outros problemas também: o pipeline de implantação e a integração com objetos de navegador da web que podem alterar o design de maneiras muito significativas.

@Kardax Sim, a discussão do LLVM IR ainda é relevante, pelo menos para alguns públicos.

Como um aparte, você mencionou "viabilidade" e "trabalhar sem falhas", mas eu sugeriria que, a este nível, esses itens são essencialmente dados como garantidos. Muitos tipos de coisas poderiam ter funcionado; a questão é: por que um foi escolhido em vez de outros?

Nenhum PR sobre isso por um tempo me diz que há pouco interesse. Vou encerrar, por favor, preencha um PR para consertar se estiver interessado.

Ainda acho que isso é relevante para o FAQ.

Aberto no. 1061.

FWIW, alguém na Microsoft conseguiu um intérprete .NET rodando no WebAssembly como um experimento: https://github.com/SteveSanderson/Blazor

https://github.com/appcypher/awesome-wasm-langs