Encontro Kyiv Go, maio de 2018:
Chumbo: - Olá a todos! Obrigado por estar aqui! Hoje temos dois palestrantes oficiais - Lyosha e Vanya. Haverá mais dois se tivermos tempo suficiente. O primeiro palestrante é Alexey Grachev, ele nos falará sobre o GopherJS.
Alexey Grachev (doravante – AG): – Sou um desenvolvedor Go e escrevo serviços web em Go. Às vezes você tem que lidar com o frontend, às vezes você tem que fazer isso manualmente. Quero falar sobre minha experiência e pesquisa sobre Go no frontend.
A lenda é esta: primeiro falaremos sobre por que queremos rodar Go no frontend, depois falaremos sobre como isso pode ser feito. Existem duas maneiras - Web Assembly e GopherJS. Vamos ver qual é o estado dessas soluções e o que pode ser feito.
O que há de errado com o front-end?
Todos concordam que está tudo bem com o frontend?
Não há testes suficientes? Construção lenta? Ecossistema? Multar.
Em relação ao frontend, gosto da citação que um dos desenvolvedores frontend disse em seu livro:
Javascript não possui um sistema de tipos. Agora vou citar os problemas que encontrei no decorrer do meu trabalho e explicar como eles são resolvidos.
O sistema de tipos em geral dificilmente pode ser chamado de sistema de tipos em Javasript - existem linhas que indicam o tipo do objeto, mas na verdade isso não tem nada a ver com tipos. Este problema é resolvido em TypeScript (um complemento para Javasript) e Flow (um verificador de tipo estático em Javascript). Na verdade, o frontend já chegou ao ponto de resolver o problema de um sistema de tipos incorretos em Javascript.
Não existe uma biblioteca padrão no navegador - existem alguns objetos integrados e funções “mágicas” nos navegadores. Mas em Javascript não existe uma biblioteca padrão como tal. Esse problema já foi resolvido uma vez pelo jQuery (todos usavam jQuery com todos os protótipos, helpers, funções que eram necessárias para funcionar). Agora todo mundo usa Lodash:
Inferno de retorno de chamada. Acho que todo mundo viu o código Javascript há cerca de 5 anos e parecia um “macarrão” de uma incrível complexidade de retornos de chamada. Agora que esse problema foi resolvido (com o lançamento do ES-15 ou ES-16), promessas foram adicionadas ao Javascript e todos podem respirar mais tranquilos por um tempo.
Até o inferno do Promice chegar... Não sei como a indústria de front-end consegue, mas eles sempre se envolvem em alguma selva estranha. Também conseguimos fazer promessas infernais. Então resolvemos esse problema adicionando uma nova primitiva - async/await:
O problema da assincronia está resolvido. Async/await é uma primitiva bastante popular em vários idiomas. Python e outros têm essa abordagem – é muito boa. Problema resolvido.
Qual problema não foi resolvido? A complexidade exponencialmente crescente dos quadros, a complexidade do ecossistema e dos próprios programas.
- A sintaxe Javascript é um pouco estranha. Todos nós conhecemos os problemas de adicionar um array e um objeto e outras piadas.
- Javascript é multiparadigma. Este é um sistema particularmente urgente agora que o ecossistema é muito grande:
- todos escrevem em estilos diferentes - alguns escrevem estruturalmente, alguns escrevem funcionalmente, diferentes desenvolvedores escrevem de forma diferente;
- de pacotes diferentes, paradigmas diferentes quando você usa pacotes diferentes;
- há muita “diversão” com a programação funcional em Javasript - a biblioteca rambda apareceu e agora ninguém consegue ler programas escritos nesta biblioteca.
- Tudo isso causa um grande impacto no ecossistema, que tem crescido incrivelmente. Os pacotes são incompatíveis entre si: alguns são baseados em promessas, alguns são baseados em async/await, alguns são baseados em retornos de chamada. Eles também escrevem em paradigmas diferentes!
- Isso torna o projeto difícil de manter. É difícil encontrar um bug se você não consegue ler o código.
O que é Web Assembly?
Os corajosos da Fundação Mozilla e de várias outras empresas criaram algo como Web Assembly. O que é isso?
- Esta é uma máquina virtual integrada ao navegador que suporta o formato binário.
- Os programas binários chegam lá e são executados quase nativamente, 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 se trata de bytecode, você pode escrever um compilador para qualquer linguagem.
- Quatro navegadores principais já são fornecidos com suporte para Web Assembly.
- Esperamos suporte nativo no Go em breve. Esta nova arquitetura já foi adicionada: GOARCH=wasm GOOS=js (em breve). Até o momento, pelo que entendi, não está funcional, mas há uma afirmação de que com certeza estará em Go.
O que fazer agora? GopherJS
Embora não tenhamos suporte para Web Assembly, existe um transpilador como o GopherJS.
- O código Go é transpilado para Javascript “puro”.
- Funciona em todos os navegadores - não há novos recursos suportados apenas por navegadores modernos (este é o Vanilla JS, que roda em qualquer coisa).
- Há suporte para quase tudo que Go tem, inclusive goroutines e canais... tudo que tanto amamos e conhecemos.
- Quase toda a biblioteca padrão é suportada, exceto aqueles pacotes que não faz sentido suportar no navegador: syscall, interações de rede (existe um cliente net/http, mas não há servidor, e o cliente é emulado via XMLHttpRequest). Em geral, toda a biblioteca padrão está disponível - aqui está no navegador, aqui está o stdlib do Go, que amamos.
- Todo o ecossistema de pacotes em Go, todas as soluções de terceiros (templates, etc.) podem ser compiladas usando GopherJS e executadas no navegador.
GopherJS é muito fácil de obter - é apenas um pacote Go normal. Vamos buscar e temos um comando GopherJS para construir o aplicativo:
Este é um olá mundo tão pequeno...
...Um programa Go normal, um pacote fmt de biblioteca padrão regular e Binding Js para acessar a API do navegador. Println será eventualmente convertido para log do console e o navegador escreverá “Olá, esquilos”! É simples assim: fazemos a construção do GopherJS – lançamos no navegador – tudo funciona!
O que você tem no momento? Ligações
Existem ligações para todas as estruturas js populares:
- JQuery;
- Angular.js;
- D3.js para plotar e trabalhar com big data;
- Reagir.js;
- VueJS;
- há até suporte para Electron (ou seja, já podemos escrever aplicativos desktop no Electron);
- e o mais engraçado é o WebGL (podemos fazer aplicações totalmente gráficas, incluindo jogos com gráficos 3D, música e todas as guloseimas);
- e muitas outras ligações para todas as estruturas e bibliotecas javascript populares.
Quadro
- Já existe um framework web desenvolvido especificamente para GopherJS - Vecty. Este é um análogo completo do React.js, mas desenvolvido apenas em Go, com as especificidades do GopherJS.
- Existem bolsas de jogos (surpresa!). Achei os dois mais populares:
- Engo;
- Ebiten.
Vou mostrar alguns exemplos de como é e o que você já pode escrever em Go:
Ou esta opção (não consegui encontrar um jogo de tiro 3D, mas talvez exista):
O que estou oferecendo?
Agora, a indústria de front-end está em tal estado que todas as linguagens que antes gritavam de Javascript irão para lá. Agora tudo será compilado em “Web Assemblies”. O que precisamos para ocupar nosso lugar de direito como Esquilos?
Tradicionalmente, Go assume que é uma linguagem de programação de sistema e praticamente não existem bibliotecas para trabalhar com a UI. Existe alguma coisa, mas está meio abandonada, meio não funcional.
E agora é uma boa chance de criar bibliotecas de UI em Go que rodarão em GopherJS! Você pode finalmente escrever sua própria estrutura! Este é o momento em que você pode escrever uma estrutura, e ela será uma das primeiras e será adotada antecipadamente, e você será uma estrela (se for uma boa estrutura).
Você pode adaptar vários pacotes diferentes que já estão no ecossistema Go às especificidades do navegador (por exemplo, mecanismo de modelo). Eles já funcionarão, você pode fazer ligações convenientes para poder renderizar facilmente o conteúdo diretamente no navegador. Além disso, você pode fazer, por exemplo, um serviço que pode renderizar a mesma coisa no servidor e no front-end, usando o mesmo código - tudo que os desenvolvedores front-end gostam (só agora em Go).
Você pode escrever um jogo! Apenas por diversão…
Eu tenho tudo.
perguntas
Pergunta (doravante denominada Q): – Escrevo em Go ou Js?
AG: – Você escreve rotinas, canais, estruturas, incorporação – tudo em Go... Você se inscreve em um evento, passa uma função lá.
AT: – Então escrevo em Js “nus”?
AG: – Não, você escreve como se estivesse em Go e se conecta à API do navegador (a API não mudou). Você pode escrever suas próprias ligações para que as mensagens sejam enviadas para o canal - não é difícil.
AT: – E quanto ao celular?
AG: – Eu definitivamente vi: existem ligações para o patch Cordova que Js executa. Em React Native - não sei; talvez exista, talvez não (eu não estava particularmente interessado). O mecanismo de jogo N-go oferece suporte a aplicativos móveis - iOS e Android.
AT: – Pergunta sobre Web Assembly. Cada vez mais espaço está sendo ocupado, apesar da compressão e do “zipping”... Não mataremos ainda mais o mundo front-end desta forma?
AG: – Web Assembly é um formato binário, e binário por padrão não pode estar na versão final mais do que texto... Você é atraído pelo tempo de execução, mas isso é o mesmo que arrastar a biblioteca Javascript padrão quando ela não está lá, então nós use um pouco de Lodash. Não sei quanto Lodash aguenta.
AT: – Obviamente menos que o tempo de execução...
AG: – Em Javascript “puro”?
AT: - Sim. Nós comprimimos antes de enviar...
AG: – Mas isso é texto... Em geral, um megabyte parece muito, mas é tudo (você tem o tempo de execução inteiro). Em seguida, você escreve sua própria lógica de negócios, o que aumentará seu binário em 1%. Até agora não vejo isso matando o frontend. Além disso, o Web Assembly funcionará mais rápido que o Javascript pelo motivo óbvio: não precisa ser analisado.
AT: – Este ainda é um ponto controverso... Ainda não existe nenhuma implementação de referência do “Vasma” (Web Assembly) para que se possa julgar de forma inequívoca. Conceitualmente sim: todos entendemos que o binário deveria ser mais rápido, mas a implementação atual do mesmo V8 é muito eficiente.
AG: - Sim.
AT: – A compilação lá funciona muito bem e não é fato que haverá uma grande vantagem.
AG: – Web Assembly também é feito por gente grande.
AT: – Parece-me que ainda é difícil julgar o Web Assembly. Já existem conversas há muitos anos, mas há poucas conquistas reais que podem ser sentidas.
AG: - Talvez. Veremos.
AT: – Não temos problemas no backend... Talvez devêssemos deixar esses problemas no frontend? Por que ir para lá?
AG: – Temos que manter uma equipe de trabalhadores da linha de frente.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com