Encontro Kyiv Go de maio de 2018:
Líder: - Ola a todos! Grazas por estar aquí! Hoxe temos dous relatores oficiais: Lyosha e Vanya. Haberá dous máis se temos tempo. O primeiro orador é Alexey Grachev, falaranos de GopherJS.
Alexey Grachev (en diante - AG): – Son programador de Go e escribo servizos web en Go. Ás veces tes que lidar co frontend, ás veces hai que subir alí con asas. Quero falar da miña experiencia e investigación en Go no frontend.
A lenda é a seguinte: primeiro falaremos de por que queremos executar Go na interface, despois falaremos de como podemos facelo. Hai dúas formas: Web Assembly e GopherJS. Vexamos en que estado están estas decisións e que se pode facer.
Que ten de malo o frontend?
Todo o mundo está de acordo en que todo está ben co frontend?
Poucas probas? Construción lenta? Ecosistema? Ben.
Respecto ao front-end, gústame unha cita que un dos desenvolvedores front-end dixo no seu libro:
Javascript non ten un sistema de tipos. Agora poñerei un nome aos problemas que atopei no curso do meu traballo e explicarei como se solucionan.
O sistema de tipos é xeralmente difícil de chamar a un sistema de tipos en Javascript: hai liñas que indican o tipo dun obxecto, pero de feito isto non ten nada que ver cos tipos. Este problema resólvese en TypeScript (complemento de Javascript) e Flow (comprobador de tipos de Javascript). De feito, o frontend xa chegou a resolver o problema dun sistema de mal tipo en Javascript.
Non hai unha biblioteca estándar no navegador como tal: hai algúns obxectos incorporados e funcións "máxicas" nos navegadores. Pero non teño unha biblioteca estándar en Javascript como tal. Este problema xa foi resolto por jQuery (todo o mundo utilizaba jQuery con todos os prototipos, axudantes, funcións que precisaban para funcionar). Agora todos usan Lodash:
inferno de devolución de chamada. Creo que todo o mundo viu o código Javascript hai uns 5 anos e parecía un "fideo" dunha incrible complexidade de devolucións de chamada. Agora este problema está resolto (co lanzamento de ES-15 ou ES-16), engadíronse promesas a Javascript e todos comezaron a respirar máis tranquilos por un tempo.
Ata que chegou o inferno de Promice... Non sei como se manexa a industria de front-end, pero sempre se meten nunha estraña selva. Tamén conseguimos facer o inferno nas "promesas". Entón resolvemos este problema engadindo unha nova primitiva - async / await:
Coa asincronía, o problema está resolto. Async/wait é un primitivo bastante popular en diferentes idiomas. Python e outros teñen este enfoque: é o suficientemente bo. Problema resolto.
Que problema non está resolto? A complexidade exponencialmente crecente dos marcos, a complexidade do ecosistema e dos propios programas.
- A sintaxe de Javascript é un pouco estraña. Todos sabemos os problemas para engadir unha matriz e un obxecto e outros trucos.
- Javascript é multiparadigma. Agora este é un sistema especialmente apremiante cando o ecosistema é moi grande:
- todos escriben en diferentes estilos: alguén escribe estruturalmente, alguén escribe funcionalmente, diferentes desenvolvedores escriben de forma diferente;
- de diferentes paquetes (paquetes) diferentes paradigmas cando usa diferentes paquetes;
- moita "diversión" coa programación funcional en Javascript: apareceu a biblioteca rambda e agora ninguén pode ler programas escritos nesta biblioteca.
- Todo isto ten un gran impacto no ecosistema, e creceu incriblemente. Os paquetes son incompatibles entre si: algúns están en promesas, outros están en asíncrono/espera, outros están en devolucións de chamada. Tamén escriben en diferentes paradigmas!
- Isto dificulta o mantemento do proxecto. É difícil atopar un erro se non podes ler o código.
Que é Web Assembly?
Os mozos valentes da Fundación Mozilla e outras moitas empresas crearon algo como Web Assembly. Que é isto?
- Esta é unha máquina virtual integrada no navegador que admite o formato binario.
- Os programas binarios chegan alí, execútanse case de forma nativa, é dicir, o navegador non precisa analizar todos os "fideos" do código javascript cada vez.
- Todos os navegadores declararon compatibilidade.
- Xa que este é un bytecode, podes escribir un compilador para calquera idioma.
- Os catro navegadores principais xa se envían con soporte de Web Assembly.
- Agardamos asistencia nativa en Go en breve. Esta nova arquitectura xa se engadiu: GOARCH=wasm GOOS=js (en breve). Polo de agora, segundo entendo, non é funcional, pero hai unha declaración de que definitivamente estará en Go.
Que facer agora? Gopher JS
Aínda que non temos soporte para Web Assembly, hai un transpiler como GopherJS.
- O código Go transpílase a Javascript "puro".
- Funciona en todos os navegadores: non hai funcións novas que só sexan compatibles cos navegadores modernos (este é Vanilla JS, que se executa en calquera cousa).
- Hai soporte para case todo o que hai en Go, incluíndo goroutines e canles... todo o que tanto nos gusta e coñecemos.
- Admítese case toda a biblioteca estándar, coa excepción daqueles paquetes que non ten sentido admitir no navegador: syscall, interaccións na rede (hai un cliente net/http, pero non un servidor, e o cliente é emulado mediante XMLHttpRequest) . En xeral, está dispoñible toda a biblioteca estándar: aquí está no navegador, aquí está a Go stdlib que nos encanta.
- Todo o ecosistema de paquetes en Go, todas as solucións de terceiros (modelos, etc.) pódense compilar con GopherJS e executarse no navegador.
Conseguir GopherJS é moi sinxelo: é só un paquete de Go normal. Facemos un go get e temos un comando GopherJS para construír a aplicación:
Aquí tes un mundo tan pequeno de ola...
...Un programa Go normal, un paquete fmt normal da biblioteca estándar e Binding Js para chegar á API do navegador. Println converterase finalmente no rexistro da consola e o navegador escribirá "Hello gophers"! É tan sinxelo: facemos a compilación de GopherJS - lanzámolo no navegador - todo funciona!
Que hai neste momento? Encadernacións
Hai enlaces para todos os frameworks js populares:
- jquery;
- Angular.js
- D3.js para trazar e traballar con big data;
- React.js
- VueJS;
- incluso hai soporte para Electron (é dicir, xa podemos escribir aplicacións de escritorio en Electron);
- e o máis divertido é WebGL (podemos facer aplicacións gráficas completas, incluíndo xogos con gráficos 3D, música e todas as golosinas);
- e moitas outras ligazóns a todos os frameworks e bibliotecas javascript populares.
Cadro
- Xa hai un marco web desenvolvido especificamente para GopherJS - Vecty. Este é un análogo completo de React.js, pero só desenvolvido en Go, coas características específicas de GopherJS.
- Hai bolsas de xogos (de súpeto!). Atopei dous dos máis populares:
- engo;
- Ebiten.
Vou demostrar un par de exemplos de como se ve e do que xa se pode escribir en Go:
Ou esta opción (non atopei un tirador 3D, pero quizais exista):
Que suxiro?
Agora a industria front-end está nun estado tal que todas as linguaxes que antes chamaban Javascript correrán alí. Agora todo compilarase en "Asembleas web". Que necesitamos para ocupar alí un lugar digno como "gophers"?
En Go, tradicionalmente afirmouse que é unha linguaxe de programación do sistema e practicamente non hai bibliotecas para traballar coa IU. Hai algo, pero está medio abandonado, medio non funcional.
E agora: unha boa oportunidade de crear bibliotecas de IU en Go que se executarán en GopherJS! Por fin podes escribir o teu propio marco! Chegou o momento no que podes escribir un marco, e será un dos primeiros e te adoptes cedo, e serás unha estrela (se é un bo marco).
Podes adaptar moitos paquetes diferentes que xa existen no ecosistema Go ás características específicas do navegador (por exemplo, o motor de modelos). Xa funcionarán, podes facer enlaces cómodos para que poidas renderizar facilmente o contido directamente no navegador. Ademais, podes crear, por exemplo, un servizo que poida render o mesmo no servidor e no front-end, usando o mesmo código, todo o que lles gusta aos desenvolvedores front-end (só agora en Go).
Podes escribir un xogo! Só por diversión…
Iso é todo o que quería dicir.
preguntas
Pregunta (en adiante denominada Q): – Escribo en Go ou Js?
AG: – Escribes rutinas, canles, estruturas, incrustacións, todo en Go… Subscribes a un evento, pasas unha función alí.
EN: - É dicir, que escribo nas Js "espidas"?
AG: - Non, escribes como en Go e conéctate á API do navegador (a API non cambiou). Podes escribir as túas propias ligazóns para que as mensaxes cheguen á canle, non é difícil.
EN: - E o móbil?
AG: - Vin seguro: hai carpetas para o parche Cordova que lanza Js. En React Native, non o sei; quizais o haxa, quizais non (non lle interese especialmente). O motor de xogos N-go admite aplicacións móbiles, tanto para iOS como para Android.
EN: – Unha pregunta sobre Web Assembly. Cada vez ocúpanse máis lugares, a pesar da concisión, do “zipping”... Non mataremos aínda máis o mundo do frontend deste xeito?
AG: - Web Assembly é un formato binario, e o binario predeterminado non pode ser máis grande que o texto na versión final... O tempo de execución é tirado, pero isto é o mesmo que tirar da biblioteca estándar de Javascript cando non está alí, polo que use un pouco de Lodash. Non sei canto tarda Lodash.
EN: - Obviamente menos que o tempo de execución...
AG: - En Javascript "puro"?
EN: - Si. Comprimimos antes de envialo...
AG: - Pero isto é texto... En xeral, un megabyte é como moito, pero iso é todo (tedes todo o tempo de execución). A continuación, escribe a túa propia lóxica empresarial que aumentará o teu binario nun 1%. Ata agora non o vexo matando o frontend. Ademais, Web Assembly funcionará máis rápido que Javascript pola razón obvia: non é necesario analizalo.
EN: - Ata agora, un punto polémico... Aínda non hai unha implementación de referencia de "Wasma" (Asemblea Web), para que se poida xulgar sen ambigüidades. Conceptualmente, si: todos entendemos que o binario debería ser máis rápido, pero a implementación actual do mesmo V8 é moi eficiente.
AG: - Si.
EN: - A compilación alí funciona moi ben e non é un feito que haxa unha gran vantaxe.
AG: - Web Assembly tamén está feito por grandes.
EN: - Ata agora, paréceme, aínda é difícil xulgar a Web Assembly. Hai moitos anos que se falan, pero son poucos os logros reais que se notan.
AG: - Pode ser. Vexamos.
EN: - Non temos problemas no backend... Quizais deberíamos deixar estes problemas no frontend? Por que ir alí?
AG: - Temos que manter o persoal de primeira liña.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com