Design: O Webasm pode substituir o Javascript no navegador?

Não estou familiarizado o suficiente com c #, mas, na verdade, acho que o wasm não pode assumir o javascript completamente.

Primeiro, se você tentou, você descobriu que o javascript é muito mais rápido do que o wasm em algumas operações de nível inferior, como "+, -, *, /" e algumas outras operações relacionadas à matemática devido à pequena sobrecarga ao chamar do JavaScript em WebAssembly e vice-versa. # 1120

Em segundo lugar, para os desenvolvedores da web, eles já estavam familiarizados com javascript e sua gramática, é desnecessário e difícil para eles construir aplicativos da web com outra linguagem de desenvolvimento que não seja da web.

Por fim, com a ajuda de " Binary AST ", o desempenho dos aplicativos da web atuais será elevado a um novo nível, sem qualquer revisão desses aplicativos.

PS:
Não importa C # ou Java, se você deseja tornar esta linguagem de programação muito mais amigável para os desenvolvedores, a eficiência desta linguagem será limitada por causa de alguns recursos de "fácil utilização" como "tipo fraco" e quaisquer outros recursos, vice-versa.

@Becavalier Pode ser que sim se você estiver tentando chamar uma função wasm a partir da sobrecarga de contexto JS, mas o tempo de execução não se comunica com Javascript até e a menos que seja exclusivamente necessário .. como consulta / manipulação de DOM, CSS inline, pinturas de tela _etc .._ Toda a execução acontecendo dentro do contexto wasm é bem mais rápida. O atraso surge quando a ponte JS é introduzida, como no caso do # 1120, você está tentando imprimir o timestamp de desempenho no contexto Javascript para uma função executada no contexto wasm, que é um atraso adicional.

Frameworks populares como Angular2 / 4, que é uma reformulação completa adotando Typescript, Android em Kotlin ou iOS em Swift, quando há um grande nome por trás de alguns frameworks ou linguagem do mundo inteiro tentam adotar a mudança.

Portanto, a questão é que existe a possibilidade de JS ser marginalizado ou até mesmo removido da imagem abstraindo as pontes de API e portando tempos de execução no navegador. Webassembly abriu a porta para compiladores de outras linguagens competirem com Javascript no navegador.

Inicialmente, costumávamos adotar tecnologias que tornavam nosso código JS mais eficiente para execução em VMs como V8 e outras, mas agora você pode escrever e compilar para um código de montagem que pode ultrapassar o código JS.

Agora você pode esperar que os compiladores para web substituam os transpiladores como TypeScript, CoffeeScript etc.

Desenvolvedores de Javascript, cruzem os dedos . Podemos esperar grandes mudanças nos próximos anos.

PS: Eu amo Javascript e C-Lang

Webassembly abriu a porta para compiladores de outras linguagens competirem com Javascript no navegador.

Sim, de fato, esse é um dos propósitos do WebAssembly.

Aqui está uma citação do FAQ da

Embora o WebAssembly permita, com o tempo, que muitas linguagens sejam compiladas para a Web, o JavaScript tem uma quantidade incrível de impulso e continuará sendo a linguagem única e privilegiada (conforme descrito acima) dinâmica da Web. Além disso, espera-se que JavaScript e WebAssembly sejam usados ​​juntos em várias configurações:

• Aplicativos C ++ completos e compilados que aproveitam o JavaScript para unir as coisas.

Lembre-se de que outras linguagens são compiladas para JavaScript há anos e continuarão a fazê-lo com ou sem WebAssembly.

Você já pode compilar C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. para JavaScript.

Você pode compilar bytecode .NET para JavaScript , você pode compilar bytecode OCaml para JavaScript , e o GWT existe há 11 anos e tem sido usado em grandes projetos.

Esses projetos já existem há muitos anos. Não é realmente uma coisa nova.

JavaScript já compete com outras linguagens. O WebAssembly apenas torna as outras linguagens mais eficientes, só isso.

Inicialmente, costumávamos adotar tecnologias que tornavam nosso código JS mais eficiente para execução em VMs como V8 e outras, mas agora você pode escrever e compilar para um código de montagem que pode ultrapassar o código JS.

Sim, porque as VMs JavaScript nunca podem atingir o desempenho nativo, devido à sobrecarga dos mecanismos JIT (e à natureza inerentemente dinâmica do JavaScript), então, se você deseja mais desempenho, precisa de um controle rígido de baixo nível da execução do código. WebAssembly oferece esse controle.

Portanto, a questão é que existe a possibilidade de JS ser marginalizado ou até mesmo removido da imagem abstraindo as pontes de API e portando tempos de execução no navegador.

Não, as pessoas continuarão a usar JavaScript.

Por muitos anos na área de trabalho, houve muitas linguagens para escolher: Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C ++, Java, etc.

As pessoas usam muitas linguagens, incluindo JavaScript. JavaScript não vai a lugar nenhum.

Mesmo em um ( muito improvável) mundo hipotético onde JavaScript não é uma linguagem de primeira classe, as pessoas ainda podem compilar JavaScript para WebAssembly.

Agora você pode esperar que os compiladores para web substituam os transpiladores como TypeScript, CoffeeScript etc.

Isso é improvável, ainda existem boas razões para as pessoas usarem TypeScript e JavaScript.

É claro que haverá alternativas ao TypeScript e algumas pessoas usarão essas alternativas, mas é improvável que o TypeScript desapareça.

Digo isso porque já existem boas alternativas ao TypeScript há anos (como o Haxe ), mas elas nunca substituíram o TypeScript.

Em 4 de setembro de 2017 às 03:42, Pauan [email protected] escreveu:
>

JavaScript já compete com outras linguagens. WebAssembly apenas faz
outras linguagens mais eficientes, só isso.

O último não é totalmente correto. Outro objetivo do Wasm é habilitar recursos
que não são suportados por JavaScript e, potencialmente, nunca serão. Para
exemplo, simultaneidade, chamadas finais ou exceções recuperáveis ​​estão todos no
roteiro.

@rossberg-chromium Certamente você está correto, eu tinha esquecido esse detalhe. Obrigado por esclarecer.

@Pauan Obrigado pelos detalhes. Embora alguns de seus pontos sejam válidos e façam sentido, não concordo com todos.

C # no lado do cliente parece promissor e um exemplo matador para evitar o Javascript completamente no estágio de desenvolvimento. ou seja, posso usar C # para escrever um webapp totalmente funcional sem precisar escrever nenhum código Javascript. Esse tipo de estrutura baseada em atitude tem uma chance provável de silenciar o legado de Javascript, pelo menos até certo ponto.

Você já pode compilar C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. para JavaScript.

Sim, o Javascript estava na imagem. Mas agora com WASM / Webasm meu motivo de compilar para Javascript mudou. Pode-se compilar diretamente para o wasm e escrever uma camada de máscara de API ou pontes em Javascript sempre que necessário, de modo que a base de desenvolvedores não precisa saber Javascript para desenvolver um webapp com Webapp, quero dizer Webapp puro, não ASP.net, tipo de framework JSP.

Lembre-se de que outras linguagens são compiladas para JavaScript há anos e continuarão a fazê-lo com ou sem WebAssembly.

Você já pode compilar C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. para JavaScript.

Embora muitas linguagens já possam compilar para JavaScript, compilar para Webasm evitaria a carga significativa e as penalidades de desempenho de tempo de execução para isso? E os problemas de desempenho se você compilasse uma linguagem C VM completa para Webasm para fazer isso dessa maneira?

Se o uso de outras linguagens resulta em problemas de desempenho inevitáveis, ou muitos lugares que violam as especificações das linguagens (por motivos de desempenho), é uma substituição parcial do JavaScript, na melhor das hipóteses, e geralmente já os vi mais usados ​​para portar código legado do que código novo para "substituir JavaScript "(exceto CoffeeScript, TypeScript, etc. que são projetados para compilar em JS).

Esses problemas podem ser resolvidos? por exemplo, com um novo compilador Ruby -> Webasm e obter desempenho comparável ao JavaScript do navegador atual?

Para usar JavaScript e Ruby (com Opal) como exemplo (como algo que tentei e basicamente abandonei anteriormente):

Em JavaScript com um operador + , ele permite que os números sejam convertidos em uma string, por exemplo

5 + " example" === "5 example"

Ruby tem uma tipificação muito mais forte, e isso não é permitido:

5 + " example"
#TypeError: String can't be coerced into Integer

Então, Opal tem que fazer seus próprios métodos positivos e bastante complexos para muitos tipos de núcleo

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

Da mesma forma para muitas operações básicas.

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

Talvez em teoria um JIT pudesse otimizar isso totalmente, mas não pense que eles estão próximos (não micro benchmark, mas para um aplicativo / página de protótipo inteiro que fiz, a versão Ruby era significativamente mais lenta) e conversões como essa parecem estar apenas fazendo o otimizadores de vida mais difícil?

E mesmo assim, algumas coisas estão erradas ou não são suportadas (embora o Webasm tenha números inteiros nativos, então isso é um começo feliz se compilar para Webasm em vez de JS):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

Posso usar C # para escrever um aplicativo da web totalmente funcional sem precisar escrever nenhum código Javascript.

Sim, e concordo que é muito legal (estou trabalhando em uma linguagem que pretendo compilar para o WebAssembly), mas meu ponto é que você já pode fazer isso, mesmo sem WebAssembly.

Pode-se compilar diretamente para o wasm e escrever uma camada de máscara de API ou pontes em Javascript sempre que necessário, de modo que a base de desenvolvedores não precisa saber Javascript para desenvolver um webapp com Webapp, quero dizer Webapp puro, não ASP.net, tipo de framework JSP.

Na verdade, e isso já é possível há muitos anos. Você não precisa esperar pelo WebAssembly, você pode começar agora : o asm.js existe há vários anos.

@wnewbery

Embora muitas linguagens já possam compilar para JavaScript, compilar para Webasm evitaria a carga significativa e as penalidades de desempenho de tempo de execução para isso? E os problemas de desempenho se você compilasse uma linguagem C VM completa para Webasm para fazer isso dessa maneira?

Isso pode ajudar nos tempos de análise, mas é improvável que ajude no desempenho do tempo de execução.

Deixe-me esclarecer uma coisa: o asm.js existe há vários anos. Ele permite que você compile um programa em JavaScript, e esse programa será executado em velocidades quase nativas. Em outras palavras, você pode executar um programa na mesma velocidade em que é executado na área de trabalho.

Portanto, já foi possível pegar uma linguagem, compilar sua VM, tempo de execução e coletor de lixo para asm.js, e você pode então executar qualquer linguagem que quiser no navegador, quase na mesma velocidade do desktop. Isso já é possível há um bom tempo.

No entanto, compilar a VM, o tempo de execução e o coletor de lixo significa que o tamanho do arquivo será muito grande (muitos megabytes).

E é difícil se comunicar com APIs JS (como o DOM).

Mas algumas pessoas fizeram isso de qualquer maneira e criaram coisas como PyPy.js, que compila o interpretador PyPy em asm.js.

Ele roda mais rápido do que o CPython (sim, é sério! O interpretador PyPy que foi compilado para JavaScript e está rodando em um navegador roda mais rápido do que o CPython nativo no desktop!)

Mas o tamanho do arquivo é muito ruim (5 megabytes compactados, 15 megabytes brutos).

Portanto, você poderia compilar VM + coletor de lixo + tempo de execução do Ruby para asm.js, e seria muito rápido, mas teria esses problemas. Em vez disso, as pessoas criam coisas como Opala.

WebAssembly é a próxima evolução do asm.js. No momento, tudo o que você pode fazer com WebAssembly, você também pode fazer com asm.js.

Então, sim, é possível compilar sua linguagem + VM + tempo de execução + coletor de lixo para WebAssembly, e será executado quase na velocidade nativa.

Mas é claro que ele tem as mesmas desvantagens do asm.js: tamanho de arquivo muito grande e é difícil se comunicar com APIs JS.

Existem sete diferenças entre WebAssembly e asm.js:

1. WebAssembly é um pouquinho (5%) mais rápido do que o asm.js em geral.

2. WebAssembly é significativamente (~ 400%) mais rápido do que asm.js se você estiver usando inteiros de 64 bits.

3. WebAssembly pode ser analisado muito mais rápido. Isso não melhora a velocidade do tempo de tempo de carregamento inicial é mais rápido com o WebAssembly.

4. O tamanho do arquivo WebAssembly é menor do que o tamanho do arquivo asm.js (cerca de 10-20% menor).

5. WebAssembly pode no futuro ganhar recursos incríveis que o asm.js não tem (threads, simultaneidade, exceções de custo zero, etc.).

6. O WebAssembly pode no futuro obter acesso ao coletor de lixo do JavaScript (o que significa que você não precisará mais compilar o coletor de lixo da sua linguagem para o WebAssembly, o que significa tamanhos de arquivo menores).

7. No futuro, o WebAssembly obterá a capacidade de usar APIs JS (como o DOM) com facilidade.

Mas mesmo no futuro, ainda será necessário compilar o tempo de execução VM + da sua linguagem no WebAssembly, portanto, o tamanho do arquivo ainda será um problema.

Se compilar o VM + runtime + coletor de lixo da sua linguagem em asm.js não é aceitável para você, provavelmente ainda não será aceitável, mesmo com WebAssembly.

E se compilar o VM + runtime + coletor de lixo da sua linguagem for aceitável para você, você já pode fazer isso agora com asm.js (e então fazer a transição facilmente para WebAssembly mais tarde).

Esses problemas podem ser resolvidos? por exemplo, com um novo compilador Ruby -> Webasm e obter desempenho comparável ao JavaScript do navegador atual?

O objetivo do WebAssembly é executar programas em velocidades nativas. Em outras palavras, executá-los na mesma velocidade em que são executados no desktop.

Portanto, se você compilar Ruby para WebAssembly, ele será executado na mesma velocidade que Ruby é executado no desktop.

Ruby é uma linguagem muito lenta. Linguagens lentas e programas lentos ainda serão lentos, mesmo quando compilados com WebAssembly.

1 / 2 == 0.5 # Should be 0, Ruby has integer division

Esse é um bug no Opal que pode ser corrigido simplesmente mudando a definição da função $rb_divide .

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

Isso pode ser corrigido fazendo com que o Opal compile strings em matrizes JavaScript (que são mutáveis).

@Pauan

WebAssembly pode no futuro ganhar recursos incríveis que o asm.js não tem (threads, simultaneidade, exceções de custo zero, etc.).

Thread é um recurso muito importante para muitas linguagens, bibliotecas, frameworks. Sem thread, muitos aplicativos criados por c ++, c #, java que dependem de multithread não podem apenas se transformar em webapp, pois pode causar um comportamento estranho (sem mencionar outra coisa boa como SIMD suporte _ no futuro (?) _). Resumindo, eu acho que asm.js não é bom o suficiente, nem desempenho nem capacidade de portabilidade, se for tão bom, deveria haver mais bibliotecas "portadas" para asm.js há muito tempo.

como todo mundo disse que o javascript não vai desaparecer apenas porque é tão popular e para suporte legado, a maioria dos navegadores ainda suportará a execução de javascript nativamente, mas acho que no futuro qualquer um que fizer novos sites com javascript irá compilá-lo para wasm para todos os ganhos de desempenho

@unmellow , para desmascarar esse mito novamente: não haveria nenhum ganho de desempenho mágico ao compilar JS para Wasm, muito pelo contrário. Se você deseja um desempenho melhor do que os motores JS são capazes de oferecer, você deve escolher um idioma melhor.

sim, desculpe, esqueci que quis dizer que analisaria mais rápido
editar: algo que pode acontecer é que o navegador não está atualizando seus mecanismos de javascript para oferecer suporte
novas versões do javascript sense as pessoas podem compilar para o wasm sem qualquer perda de desempenho

Eu não estou muito confortável em chutar uma multa de um ano atrás, mas, por uma questão de discussão e apenas um pequeno discurso retórico.

Posso ver que muitas pessoas estão céticas com a ideia de substituir o Javascript pelo WASM, mas uma coisa é que o WASM não trata apenas de desempenho. O que as pessoas geralmente esquecem é que Javascript não é a linguagem que desejam (ou desejavam). Quer dizer, pelo menos, o Javascript básico não é o que as pessoas querem. Mais e mais pessoas estão optando por transpiladores, que são basicamente compiladores para linguagens de terceiros. Isso é simplesmente porque as pessoas desistiram de confiar em padrões e desviaram para soluções de usuário (?).

Mas a transpilação é, por natureza, muito mais difícil do que a compilação. O problema matemático de mapear um idioma para outro nem sempre se limita ao escopo local. Algumas informações contextuais precisam ser transportadas para o outro lado, e fazer isso corretamente é um problema difícil. É por isso que os transpilers não semelhantes a Javascript não são amplamente adotados (ou por que não se deve confiar neles).

Além disso, há um problema com esforços duplicados. Transpiladores são compiladores e empacotadores são linkers. Todos nós temos essas ferramentas há muito tempo. Módulos, trepidação de árvore, divisão de código, carregamento dinâmico / lento, gerenciamento de ativos, etc. Nada é genuinamente novo, mas as pessoas precisam de novas ferramentas para ter esses recursos apenas para a web, o que não é amigável para soluções não-web.

Não é como se o WASM fosse mudar tudo em um dia. Javascript tem um ecossistema bem construído agora, enquanto outras linguagens não. Vou levar algum tempo antes que o Javascript realmente chegue a algum lugar, mas isso certamente acontecerá a longo prazo.

Javascript está caminhando, o que considero ser uma direção horrível, então, dou boas-vindas a um substituto do WASM. Acho que, embora tenha havido melhorias significativas, muito da comunidade e da direção foram enganadas nos últimos anos. Eu gostaria mais que uma linguagem adequada para ... não necessariamente para tomar o seu lugar, mas para ser um competidor direto, então eu não tive que escrever esse novo sabor desagradável de JS e seus "frameworks" que apareceram.

@spencerudnick Nunca escreveu assembly para obter ganhos de desempenho que você não consegue com o C?