Get best of the week

Alexey Grachev: Go Frontend

Kyiv Go Meetup maio de 2018:



Anfitrião: - Olá pessoal! Obrigado por ter vindo aqui! Hoje temos dois oradores oficiais - Lesha e Vanya. Haverá mais dois se tivermos tempo suficiente. O primeiro orador é Alexey Grachev, ele nos falará sobre o GopherJS.

Alexey Grachev (doravante - AG): - Sou desenvolvedor de Go e escrevo serviços da Web no Go. Às vezes você tem que lidar com o front-end, às vezes você tem que subir lá com canetas. Quero falar sobre minha experiência e pesquisa. Vá no front-end.

A lenda é a seguinte: primeiro falaremos sobre por que queremos executar o Go no front-end, depois falaremos sobre como isso pode ser feito. Existem duas maneiras - Web Assembly e GopherJS. Vamos ver em que estado essas decisões são e o que pode ser feito.

O que há de errado com o frontend?


Todos concordam que está tudo bem com o frontend?



Existem alguns testes? Montagem lenta? Ecossistema? Boa.

Em relação ao front-end, gosto da citação que um dos desenvolvedores de front-end disse em seu livro:



Não existe um sistema de tipos em Javascript. Agora vou citar os problemas que encontrei no decorrer do meu trabalho e explicar como eles são resolvidos.

Geralmente, é difícil chamar um sistema de tipos de Javasript - existem linhas que indicam o tipo de um objeto, mas, na realidade, isso não tem nada a ver com tipos. Esse problema foi resolvido no TypeScript (um complemento para Javasript) e no Flow (tipos de verificador estático em Javascript). Na verdade, o front-end já alcançou a solução para o problema de um sistema de tipo ruim em Javascript.



Não existe uma biblioteca padrão no navegador, como tal - existem alguns objetos internos e funções "mágicas" nos navegadores. Mas eu não tenho uma biblioteca padrão em Javascript, como tal. Esse problema já foi resolvido pelo jQuery (todos usavam o jQuery com todos os protótipos, ajudantes, funções necessárias para o trabalho). Agora todo mundo está usando o Lodash:



inferno de retorno de chamada . Acho que todo mundo viu o código Javascript há cerca de 5 anos e parecia "macarrão" das incríveis complexidades dos retornos de chamada. Agora, esse problema foi resolvido (com o lançamento do ES-15 ou ES-16), eles acrescentaram promessas ao Javascript e todos começaram a respirar mais facilmente por um tempo.



Até o inferno da Promice chegar ... eu não sei como o setor de front-end gerencia, mas eles constantemente se envolvem em algumas situações estranhas. Eles também conseguiram fazer o inferno nas "promessas". Eles resolveram esse problema adicionando uma nova primitiva - assíncrona / aguardada:



o problema é resolvido com assincronia. Async / waitit é um primitivo bastante popular em diferentes idiomas. Em "Python" e em outros, existe essa abordagem - é boa o suficiente. O problema está resolvido.

Que problema não foi resolvido? A complexidade das estruturas que crescem exponencialmente, a complexidade do ecossistema e dos próprios programas.



  • A sintaxe do Javasript é um pouco estranha. Todos conhecemos os problemas de adicionar uma matriz, um objeto e outras piadas.
  • Javascript é multi-paradigma. Agora é um sistema particularmente urgente quando o ecossistema é muito grande:

    • todo mundo escreve em estilos diferentes - alguém escreve estruturalmente, alguém escreve funcionalmente, desenvolvedores diferentes escrevem de maneira diferente;
    • de pacotes diferentes, paradigmas diferentes quando você usa pacotes diferentes;
    • há muita diversão na programação funcional em Javasript - a biblioteca rambda apareceu e agora ninguém pode ler os programas escritos nesta biblioteca.

  • Tudo isso causa um grande impacto no ecossistema e cresceu incrivelmente. Os pacotes são incompatíveis entre si: alguém sob promessas, alguém em assíncrono / espera, alguém em retorno de chamada. Eles também escrevem em diferentes paradigmas!
  • Isso dificulta a manutenção do projeto. É difícil encontrar um erro se você não conseguir ler o código.

O que é Web Assemly?


Os caras corajosos da Mozilla Foundation e várias outras empresas criaram algo como Web Assembly. O que é isso?



  • Esta é uma máquina virtual embutida no navegador que suporta o formato binário.
  • Os programas binários chegam lá, são executados quase de forma nativa, ou seja, o navegador não precisa analisar todo o "macarrão" do código javascript todas as vezes.
  • Todos os navegadores declararam suporte.
  • Como este é um bytecode, você pode escrever um compilador para qualquer idioma.
  • Quatro principais navegadores já vêm com suporte para Web Assembly.
  • Em breve, aguardamos suporte nativo no Go. Essa nova arquitetura já foi adicionada: GOARCH = wasm GOOS = js (em breve). Até agora, pelo que entendi, não é funcional, mas há uma declaração de que definitivamente estará no Go.

O que fazer agora? Gopherjs


Embora não tenhamos suporte para Web Assembly, existe um transportador como o GopherJS.



  • Transpiles de código para Javascript puro.
  • – , ( Vanilla JS, ).
  • , Go, … – , .
  • , , : syscall, net- ( net/http-, , XMLHttpRequest). – , stdlib Go, .
  • Go, ( .) GopherJS .

O GopherJS é muito fácil de obter - este é um pacote Go normal. Fazemos o get get e temos a equipe do GopherJS para criar o aplicativo:



Aqui está um mundo olá tão pequeno ...



... Um programa Go regular, um pacote fmt regular da biblioteca padrão e Js Binding para acessar a API do navegador. Eventualmente, o Println será convertido no log do console e o navegador escreverá "Olá Gopher"! É simples assim: nós construímos o GopherJS - executamos em um navegador - tudo funciona!

O que há no momento? Ligações




Existem ligações para todas as estruturas js populares:

  • JQuery
  • Angular.js;
  • D3.js para criar gráficos e trabalhar com big data;
  • React.js;
  • VueJS;
  • existe até suporte para o Electron (ou seja, agora podemos escrever aplicativos de desktop no Electron);
  • e o mais engraçado é o WebGL (podemos criar aplicativos gráficos completos, incluindo jogos com gráficos 3D, música e todas as vantagens);
  • e muitos outros fichários para todas as estruturas e bibliotecas javascript populares.

Estrutura


  1. Já existe uma estrutura da web especialmente desenvolvida para o GopherJS - Vecty. Este é um análogo completo do React.js, mas desenvolvido apenas no Go, com as especificidades do GopherJS.
  2. Existem malas de caça (de repente!). Encontrei dois dos mais populares:

    • Engo;
    • Ebiten.

Vou demonstrar alguns exemplos de como isso se parece e o que você pode escrever no Go now:



Ou essa opção (não encontrei um shooter em 3D, mas talvez seja):



O que eu sugiro?


Agora, o setor de front-end está em tal estado que todos os idiomas que clicaram em Javascript antes disso vão chegar lá. Agora todos serão compilados em Web Assemblies. O que precisamos para tomar um lugar digno lá como "esquilos"?



Tradicionalmente, o Go é uma linguagem de programação do sistema e praticamente não há bibliotecas para trabalhar com a interface do usuário. Algo está lá, mas está meio abandonado, meio não funcional.

E aqui está uma boa chance de criar bibliotecas de UI no Go que serão executadas no GopherJS! Você pode finalmente escrever sua própria estrutura! Chegou a hora em que você pode escrever uma estrutura, e ela será uma das primeiras e receberá uma adaptação precoce, e você será uma estrela (se for uma boa estrutura).

Você pode adaptar muitos pacotes diferentes que já estão no ecossistema Go às especificidades do navegador (por exemplo, mecanismo de modelo). Eles já funcionam, você pode fazer ligações convenientes para poder renderizar conteúdo diretamente no navegador. Além disso, você pode criar, por exemplo, um serviço que pode renderizar a mesma coisa no servidor e no front-end usando o mesmo código - tudo é como os desenvolvedores de front-end gostam (somente agora no Go).

Você pode escrever um jogo! Só por diversão ...

eu tenho.



Questões


Pergunta (a seguir - Q): - Escrevo em Go ou em Js?

AG: - Você escreve rotinas, canais, estruturas, incorporação no Go - é isso ... Você se inscreve em um evento, passa uma função lá.

P: - Ou seja, eu escrevo nos Js “vazios”?

AG: - Não, você escreve como se estivesse em movimento e se conecta à API do navegador (a API não mudou ao mesmo tempo). Você pode escrever suas ligações para que as mensagens cheguem ao canal - é fácil.

P: - E o celular?

AG: - Eu definitivamente vi: existem pastas para o patch Cordova que Js lança. No React Native, eu não sei; talvez exista, talvez não (não esteja realmente interessado). O mecanismo de jogos N-go também suporta aplicativos móveis - iOs e Android.

AT:- Pergunta sobre Web Assembly. Mais e mais lugares estão ocupados, apesar do aperto, "fechando" ... Poderíamos matar o mundo front-end dessa maneira ainda mais?

AG: - O Web Assembly é um formato binário, e o binário por padrão não pode estar na versão final mais do que o texto ... o tempo de execução o atrai, mas é o mesmo que a biblioteca Javascript padrão, quando não existe, por isso usamos alguns algum dia lodash. Não sei quanto custa Lodash.

P: - Explicitamente menor que o tempo de execução ...

AG: - No Javascript "puro"?

Q: - sim. Nós apertamos antes de enviá-lo ...

AG:- Mas este é o texto ... Em geral, megabytes são muitos, mas é tudo (você tem todo o tempo de execução). Em seguida, você escreve sua lógica de negócios, o que aumentará seu binário em 1%. Até eu ver isso matar o frontend. Além disso, o Web Assembly será executado mais rápido que o Javascript pelo motivo óbvio - ele não precisa ser analisado.

P: - Até agora, um momento polêmico ... Ainda não há uma implementação de referência do “Vasma” (Web Assembly), para que você possa julgar claramente. Conceitualmente - sim: todos entendemos que o binário deve ser mais rápido, mas a implementação atual do mesmo V8 é muito eficaz.

AG: - Sim.

P: - A compilação funciona muito bem lá e não é um fato que haverá uma grande vantagem.

AG: - O Web Assembly também está se destacando.

AT:- Até agora, parece-me, ainda é difícil julgar a Web Assembly. As discussões acontecem há muitos anos e há poucas realizações reais que podem ser sentidas.

AG: - Talvez. Vamos ver.

P: - Não temos problemas no back-end ... Talvez deixe esses problemas no front-end? Por que subir lá?

AG: - Temos que manter o pessoal da linha de frente.


Um pouco de publicidade :)


Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores de nível básico que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

More articles:


All Articles