Kyiv Go Meetup Maio 2018:
Apresentador: – Olá a todos! Obrigado por estarem aqui! Hoje temos dois palestrantes oficiais – Lyosha e Vanya. Haverá mais dois, se tivermos tempo. O primeiro palestrante é Aleksey Grachev, que nos falará sobre GopherJS.
Aleksey Grachev (daqui em diante – AG): – Sou desenvolvedor Go e escrevo serviços web em Go. Às vezes, preciso lidar com o frontend, e em algumas ocasiões preciso entrar lá manualmente. Quero compartilhar minhas experiências e pesquisas sobre Go no frontend.
A ideia é a seguinte: primeiro falaremos sobre por que queremos rodar Go no frontend, depois discutiremos como isso pode ser feito. Existem dois caminhos – Web Assembly e GopherJS. Vamos ver em que estado esses soluções estão e o que pode ser feito.
O que há de errado com o frontend?
Todos concordam que está tudo bem com o frontend?
Poucos testes? Compilação lenta? Ecossistema? Tudo certo.
Quanto ao frontend, gosto de uma citação que um dos desenvolvedores frontend disse em seu livro:
JavaScript não tem sistema de tipos. Agora vou mencionar os problemas que encontrei ao longo do meu trabalho e explicar como eles são resolvidos.
Na verdade, é difícil chamar o sistema de tipos de sistema de tipos em JavaScript – há strings que designam o tipo de objeto, mas na verdade isso não tem relação alguma com tipos. Este problema foi resolvido no TypeScript (uma camada sobre JavaScript) e no Flow (verificador estático de tipos em JavaScript). Na verdade, o frontend já chegou à solução do problema do fraco sistema de tipos em JavaScript.
Não há uma biblioteca padrão no navegador como tal – existem alguns objetos embutidos e funções "mágicas" nos navegadores. Mas em JavaScript, a biblioteca padrão não existe. Este problema já foi resolvido pelo jQuery (todos usavam jQuery com todos os protótipos, helpers, funções necessárias para funcionar). Atualmente, todos usam Lodash:
Callback hell. Creio que todos já viram código em JavaScript há cerca de 5 anos, e ele parecia uma "macarronada" de callbacks incrivelmente entrelaçados. Agora, esse problema foi resolvido (com o lançamento do ES-15 ou ES-16), promessas (promises) foram adicionadas ao JavaScript e todos puderam respirar um pouco mais fácil por um tempo.
Até que chegou o Promice hell… Não sei como a indústria do frontend consegue, mas eles constantemente se empurram para caminhos estranhos. Acabaram fazendo hell até com "promises". Depois, resolveram esse problema adicionando um novo primitivo – async/await:
O problema com a assíncrono está resolvido. Async/await é um primitivo bastante popular em várias linguagens. Em Python e em outras, existe essa abordagem – ela é bastante boa. O problema está resolvido.
Qual problema não foi resolvido? A crescente complexidade geométrica dos frameworks, a complexidade do ecossistema e da própria programação.
- A sintaxe do JavaScript é um pouco estranha. Todos nós conhecemos os problemas com a soma de arrays e objetos e outras peculiaridades.
- JavaScript é multiparadigma. Agora, isso é um sistema particularmente relevante, pois o ecossistema é muito grande:
- todos escrevem em estilos diferentes – alguns escrevem de forma estrutural, outros funcionalmente, diferentes desenvolvedores escrevem de maneiras diferentes;
- de diferentes pacotes (packages) vêm diferentes paradigmas, quando você utiliza pacotes diversos;
- há muita 'diversão' com programação funcional em JavaScript – apareceu a biblioteca Ramda e agora ninguém consegue ler programas escritos nessa biblioteca.
- Tudo isso traz um grande impacto no ecossistema, que cresceu de forma incrível. Os pacotes são incompatíveis entre si: alguns usam promessas, outros async/await, e alguns callbacks. E ainda escrevem em paradigmas diferentes!
- Isso leva a dificuldades na manutenção do projeto. É complicado encontrar bugs se você não consegue ler o código.
O que é Web Assembly?
Os competentes pessoal da Mozilla Foundation e de outras empresas criaram algo chamado Web Assembly. O que é isso?
- É uma máquina virtual embutida no navegador que suporta um formato binário.
- Programas binários vão para lá e são executados praticamente de forma nativa, ou seja, o navegador não precisa interpretar todo o 'macarrão' do código JavaScript a cada vez.
- Todos os navegadores declararam suporte.
- Como é bytecode, você pode escrever um compilador para qualquer linguagem.
- Os quatro principais navegadores já vêm com suporte ao Web Assembly.
- Em breve, esperamos suporte nativo em Go. Essa nova arquitetura já foi adicionada: GOARCH=wasm GOOS=js (em breve). Por enquanto, pelo que entendo, ela não está funcional, mas há uma declaração de que isso definitivamente estará no Go.
O que fazer agora? GopherJS
Enquanto não temos suporte ao Web Assembly, existe um transpiler chamado GopherJS.
- O código em Go é transpileado para 'JavaScript limpo'.
- Ele é executado em todos os navegadores – não há novos recursos que são suportados apenas por navegadores modernos (é Vanilla JS, que roda em qualquer coisa).
- Há suporte para quase tudo que existe no Go, incluindo goroutines e canais… – tudo o que amamos e conhecemos.
- Praticamente toda a biblioteca padrão é suportada, exceto aqueles pacotes que não fazem sentido ser suportados no navegador: syscall, interações de rede (existe um cliente net/http, mas não um servidor, e o cliente é emulado através do XMLHttpRequest). Em geral, toda a biblioteca padrão está disponível – aqui está ela no navegador, aqui está a stdlib Go que amamos.
- Todo o ecossistema de pacotes em Go, todas as soluções de terceiros (templatização e outras) podem ser compiladas usando GopherJS e executadas no navegador.
Obter GopherJS é muito fácil – é um pacote Go comum. Fazemos go get e temos o comando GopherJS para compilar o aplicativo:
Aqui está um pequeno hello world…
…Um programa Go comum, o pacote fmt da biblioteca padrão, e o Binding Js para acessar a API do navegador. O Println no final será convertido em console log e o navegador escreverá 'Hello gophers'! É assim tão simples: fazemos GopherJS build – executamos no navegador – tudo funciona!
O que temos até agora? Bindings
Existem bindings para todos os frameworks js populares:
- JQuery;
- Angular.js;
- D3.js para criação de gráficos e manipulação de grandes dados;
- React.js;
- VueJS;
- até suporte para Electron (ou seja, já podemos escrever aplicativos desktop em 'Electron');
- e o mais divertido – é o WebGL (podemos criar aplicativos holográficos, incluindo jogos com gráficos 3D, música e todas as funcionalidades);
- e muitos outros bindings para todos os frameworks e bibliotecas javascript populares.
Framework
- Já existe um framework web desenvolvido especificamente para GopherJS – Vecty. É um equivalente completo do React.js, mas desenvolvido em Go, com a especificidade do GopherJS.
- Existem motores de jogo (surpreendentemente!). Eu encontrei os dois mais populares:
- Engo;
- Ebiten.
Vou demonstrar alguns exemplos de como isso fica e o que já podemos escrever em Go:
Ou essa opção (não achei um jogador 3D, mas pode ser que exista):
O que eu proponho?
Atualmente, a indústria de frontend está em um estado em que todas as linguagens que anteriormente se lamentavam sobre Javascript estão agora entrando. Agora todos estarão se compilando para 'Web Assembly'. O que precisamos para ocupar um lugar digno lá como 'gophers'?
No Go, é tradicionalmente visto como uma linguagem de programação de sistema, e praticamente não existem bibliotecas para trabalhar com UI. Há algo, mas está meio abandonado e meio funcional.
E agora – é uma boa oportunidade para fazer bibliotecas de UI em Go, que serão executadas no GopherJS! Finalmente, é possível escrever seu próprio framework! Chegou o momento em que você pode criar um framework que será um dos primeiros e obterá adoção precoce, e você será uma estrela (se for um bom framework).
É possível adaptar uma infinidade de pacotes que já existem no ecossistema Go para a especificidade do navegador (por exemplo, um motor de template). Eles já funcionam, e você pode criar wrappers convenientes para renderizar conteúdo diretamente no navegador. Além disso, você pode criar, por exemplo, um serviço que consiga renderizar a mesma coisa no servidor e no frontend, usando o mesmo código – tudo como os desenvolvedores de frontend gostam (só que agora em Go).
Você pode criar um jogo! Apenas por diversão…
Isso é tudo.
Perguntas
Pergunta (a seguir – P): – Eu escrevo em Go ou em Js?
AG: – Você escreve em Go, com goroutines, canais, estruturas, embedding – tudo... Você se inscreve em um evento, passa uma função para lá.
P: – Então, eu estou escrevendo em "JavaScript puro"?
AG: – Não, você está escrevendo como se fosse em Go e se conectando à API do navegador (a API, por sua vez, não mudou). Você pode escrever seus próprios wrappers para que mensagens cheguem ao canal – não é difícil.
P: – E quanto ao mobile?
AG: – Eu definitivamente vi: há bindings para o patch do Cordova, que o Js executa. No React Native – não sei; pode haver, pode não haver (não me interessei muito). O motor de jogo N-go suporta aplicativos móveis – tanto iOS quanto Android.
P: – Pergunta sobre Web Assembly. O espaço está ocupando cada vez mais, apesar da compressão, "zipagem"... Não estaremos destruindo ainda mais o mundo do frontend desse jeito?
AG: – Web Assembly é um formato binário, e binário por padrão não pode ser maior no release final do que texto... Você está puxando runtime, mas isso é o mesmo que puxar a biblioteca padrão do Javascript quando ela não está lá, então usamos algum Lodash. Não sei quanto o Lodash ocupa.
P: – Claramente menos do que o runtime…
AG: – Em Javascript "puro"?
P: – Sim. Estamos comprimindo antes de enviar...
AG: – Mas isso é um texto… Em geral, um megabyte parece muito, mas é tudo (você tem todo o runtime). Depois, você escreve sua lógica de negócios, que aumentará seu binary em 1%. Até agora, não vejo isso como um problema para o frontend. Além disso, o Web Assembly funcionará mais rápido que o Javascript por uma razão óbvia – ele não precisa ser analisado.
P: – Por enquanto, é um ponto controverso… Ainda não existe uma implementação padrão do "Vasm" (Web Assembly) para que possamos julgar de forma inequívoca. Conceitualmente – sim: todos nós entendemos que o binary deve ser mais rápido, mas a implementação atual do V8 é muito eficiente.
AG: – Sim.
P: – A compilação lá realmente funciona muito bem e não é fato que haverá uma grande vantagem.
AG: – O Web Assembly também é feito por grandes caras.
P: – Por enquanto, parece que ainda é difícil julgar sobre o Web Assembly. Já há anos estamos discutindo, mas as realizações reais que podemos tocar são poucas.
AG: – Tal vez. Vamos ver.
P: – Não temos problemas no backend… Talvez, deixar esses problemas no frontend? Por que me meter lá?
AG: – Temos que manter uma equipe de frontenders.
Um pouco de publicidade 🙂
Obrigado por permanecer conosco. Você gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. , uma alternativa única aos servidores entry-level, que criamos para você: (disponíveis opções com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterdã? Somente conosco na Holanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partir de $99! Leia sobre
Fonte: habr.com
