Trobada Kíev Go de maig de 2018:
Moderador: - Hola a tots! Gràcies per ser aquí! Avui tenim dos ponents oficials: Lyosha i Vanya. N'hi haurà dos més si tenim prou temps. El primer ponent és Alexey Grachev, ens parlarà de GopherJS.
Alexey Grachev (d'ara endavant - AG): – Sóc desenvolupador de Go i escric serveis web a Go. De vegades t'has de tractar amb la interfície, de vegades has d'entrar-hi manualment. Vull parlar de la meva experiència i investigació sobre Go al frontend.
La llegenda és aquesta: primer parlarem de per què volem executar Go a la interfície i després parlarem de com es pot fer això. Hi ha dues maneres: Web Assembly i GopherJS. Vegem quin és l'estat d'aquestes solucions i què es pot fer.
Què passa amb el frontend?
Tothom està d'acord que tot està bé amb el frontend?
No hi ha prou proves? Construcció lenta? Ecosistema? Bé.
Pel que fa a la interfície, m'agrada la cita que va dir un dels desenvolupadors de la interfície al seu llibre:
Javascript no té un sistema de tipus. Ara anomenaré els problemes que he trobat durant el meu treball i explicaré com es resolen.
El sistema de tipus difícilment es pot anomenar sistema de tipus a Javasript: hi ha línies que indiquen el tipus d'objecte, però de fet això no té res a veure amb els tipus. Aquest problema es resol amb TypeScript (un complement de Javasript) i Flow (un verificador de tipus estàtic a Javascript). De fet, el frontend ja ha arribat al punt de resoldre el problema d'un sistema de tipus dolent en Javascript.
No hi ha una biblioteca estàndard al navegador com a tal: hi ha alguns objectes integrats i funcions "màgiques" als navegadors. Però a Javascript no hi ha una biblioteca estàndard com a tal. Aquest problema ja va ser resolt una vegada per jQuery (tothom va utilitzar jQuery amb tots els prototips, ajudants, funcions que es necessitaven per funcionar). Ara tothom fa servir Lodash:
L'infern de retorn de trucada. Crec que tothom va veure el codi Javascript fa uns 5 anys i semblava un "fideus" d'una complexitat increïble de trucades. Ara s'ha resolt aquest problema (amb el llançament de l'ES-15 o l'ES-16), s'han afegit promeses a Javascript i tothom pot respirar més tranquil durant un temps.
Fins que va arribar l'infern de Promice... No sé com es gestiona la indústria del front-end, però sempre s'endinsen a una jungla estranya. També hem aconseguit fer un infern amb promeses. A continuació, vam resoldre aquest problema afegint un nou primitiu: async/wait:
El problema de l'asincronia està resolt. Async/wait és una primitiva força popular en diversos idiomes. Python i altres tenen aquest enfocament: és força bo. Problema resolt.
Quin problema no està resolt? La complexitat exponencial dels marcs, la complexitat de l'ecosistema i els propis programes.
- La sintaxi de Javascript és una mica estranya. Tots coneixem els problemes amb afegir una matriu i un objecte i altres acudits.
- Javascript és multiparadigma. Aquest és un sistema especialment urgent ara quan l'ecosistema és molt gran:
- tothom escriu en diferents estils: alguns escriuen estructuralment, alguns escriuen funcionalment, diferents desenvolupadors escriuen de diferents maneres;
- de diferents paquets, diferents paradigmes quan utilitzeu diferents paquets;
- Hi ha molta "diversió" amb la programació funcional a Javasript: va aparèixer la biblioteca rambda i ara ningú pot llegir programes escrits en aquesta biblioteca.
- Tot això té un gran impacte en l'ecosistema, i ha crescut de manera increïble. Els paquets són incompatibles entre si: alguns es basen en promeses, altres es basen en async/wait, alguns es basen en devolucions de trucada. També escriuen en diferents paradigmes!
- Això fa que el projecte sigui difícil de mantenir. És difícil trobar un error si no pots llegir el codi.
Què és Web Assembly?
Els valents de la Fundació Mozilla i d'altres empreses van idear una cosa com Web Assembly. Què és això?
- Aquesta és una màquina virtual integrada al navegador que admet el format binari.
- Els programes binaris hi arriben i s'executen gairebé de manera nativa, és a dir, el navegador no necessita analitzar tots els "fideus" del codi javascript cada vegada.
- Tots els navegadors han declarat suport.
- Com que es tracta de bytecode, podeu escriure un compilador per a qualsevol idioma.
- Quatre navegadors principals ja s'envien amb suport Web Assembly.
- Esperem suport natiu a Go aviat. Aquesta nova arquitectura ja s'ha afegit: GOARCH=wasm GOOS=js (en breu). Fins ara, segons tinc entès, no és funcional, però hi ha una declaració que definitivament estarà a Go.
Què fer ara? Gopher JS
Tot i que no tenim suport per a Web Assembly, hi ha un transpiler com GopherJS.
- El codi Go es transmet a Javascript "pur".
- S'executa a tots els navegadors: no hi ha funcions noves que només siguin compatibles amb els navegadors moderns (es tracta de Vanilla JS, que funciona amb qualsevol cosa).
- Hi ha suport per a gairebé tot el que té Go, incloses les goroutines i els canals... tot el que estimem i sabem tant.
- S'admet gairebé tota la biblioteca estàndard, excepte aquells paquets que no té sentit suportar al navegador: syscall, interaccions en xarxa (hi ha un client net/http, però no un servidor, i el client s'emula mitjançant XMLHttpRequest). En general, tota la biblioteca estàndard està disponible: aquí està al navegador, aquí hi ha l'stdlib de Go, que ens encanta.
- Tot l'ecosistema de paquets a Go, totes les solucions de tercers (plantilles, etc.) es poden compilar mitjançant GopherJS i executar-se al navegador.
GopherJS és molt fàcil d'aconseguir: només és un paquet Go normal. Anem a buscar i tenim una ordre GopherJS per construir l'aplicació:
Aquest és un món tan petit hola...
...Un programa Go normal, un paquet fmt de biblioteca estàndard normal i Binding Js per arribar a l'API del navegador. Println finalment es convertirà al registre de la consola i el navegador escriurà "Hola gophers"! És així de senzill: fem la creació de GopherJS, l'iniciem al navegador, tot funciona!
Què tens en aquest moment? Enquadernacions
Hi ha enllaços per a tots els frameworks js populars:
- JQuery;
- Angular.js;
- D3.js per traçar i treballar amb big data;
- React.js;
- VueJS;
- fins i tot hi ha suport per a Electron (és a dir, ja podem escriure aplicacions d'escriptori a Electron);
- i el més divertit és WebGL (podem fer aplicacions completes, incloent jocs amb gràfics en 3D, música i totes les llaminadures);
- i moltes altres vinculacions a tots els frameworks i biblioteques javascript populars.
Marc
- Ja hi ha un marc web desenvolupat específicament per a GopherJS - Vecty. Aquest és un anàleg complet de React.js, però només desenvolupat a Go, amb les especificitats de GopherJS.
- Hi ha bosses de joc (sorpresa!). Vaig trobar els dos més populars:
- Engo;
- Ebiten.
Us mostraré un parell d'exemples de com es veu i què ja podeu escriure a Go:
O aquesta opció (no he pogut trobar cap shooter en 3D, però potser existeix):
Què estic oferint?
Ara la indústria del front-end es troba en un estat tal que tots els idiomes que abans cridaven des de Javascript s'hi precipitaran. Ara tot es compilarà a "Assemblys web". Què necessitem per ocupar-hi el lloc que ens correspon com a Gophers?
Go ha assumit tradicionalment que és un llenguatge de programació del sistema i pràcticament no hi ha biblioteques per treballar amb la interfície d'usuari. Hi ha alguna cosa, però és mig abandonat, mig no funcional.
I ara és una bona oportunitat per crear biblioteques d'interfície d'usuari a Go que s'executin a GopherJS! Per fi pots escriure el teu propi marc! Aquest és el moment en què pots escriure un framework, i serà un dels primers i aconseguiràs una adopció anticipada, i seràs una estrella (si és un bon framework).
Podeu adaptar molts paquets diferents que ja es troben a l'ecosistema Go a les especificitats del navegador (per exemple, el motor de plantilles). Ja funcionaran, podeu fer enllaços convenients perquè pugueu renderitzar fàcilment el contingut directament al navegador. A més, podeu crear, per exemple, un servei que pugui representar el mateix al servidor i al front-end, utilitzant el mateix codi, tot el que els agrada als desenvolupadors front-end (només ara a Go).
Pots escriure un joc! Només per diversió…
Això és tot el que volia dir.
Les vostres preguntes
Pregunta (d'ara endavant anomenada Q): – Escric en Go o Js?
AG: – Escrius rutines, canals, estructures, incrustacions – tot a Go... Et subscrius a un esdeveniment, hi passes una funció.
AT: – Així que escric en Js “nues”?
AG: – No, escrius com a Go i et connectes a l'API del navegador (l'API no ha canviat). Podeu escriure els vostres propis enllaços perquè els missatges s'enviïn al canal, no és difícil.
AT: – Què passa amb el mòbil?
AG: – Definitivament vaig veure: hi ha enllaços per al pegat de Còrdova que executa Js. A React Native - No ho sé; potser n'hi ha, potser no (no m'interessava especialment). El motor de jocs N-go admet ambdues aplicacions mòbils, tant per a iOS com per a Android.
AT: – Pregunta sobre Web Assembly. Cada cop s'ocupa més espai, malgrat la compressió i el “zipping”... No matarem encara més el món front-end d'aquesta manera?
AG: – Web Assembly és un format binari i, per defecte, el binari no pot estar a la versió final més que text... Us atreu al temps d'execució, però això és el mateix que arrossegar la biblioteca Javascript estàndard quan no hi és, així que utilitzar una mica de Lodash. No sé quant pren Lodash.
AT: - Òbviament menys que el temps d'execució...
AG: – En Javascript “pur”?
AT: - Sí. Ho comprimim abans d'enviar-lo...
AG: – Però això és text... En general, un megabyte sembla molt, però això és tot (tens tot el temps d'execució). A continuació, escriu la teva pròpia lògica empresarial, que augmentarà el teu binari un 1%. Fins ara no veig que això mati el frontend. A més, Web Assembly funcionarà més ràpid que Javascript per la raó òbvia: no cal analitzar-lo.
AT: – Aquest és encara un punt polèmic... Encara no hi ha cap implementació de referència de “Vasma” (Web Assembly) perquè es pugui jutjar sense ambigüitats. Conceptualment, sí: tots entenem que el binari hauria de ser més ràpid, però la implementació actual del mateix V8 és molt eficient.
AG: - Sí.
AT: – La recopilació allà funciona molt bé i no és un fet que hi hagi un gran avantatge.
AG: – Web Assembly també el fan grans.
AT: – Em sembla que encara és difícil jutjar Web Assembly. Fa molts anys que hi ha converses, però hi ha pocs èxits reals que es poden notar.
AG: - Pot ser. Ho veure'm.
AT: – No tenim problemes al backend... Potser hauríem de deixar aquests problemes al frontend? Per què anar-hi?
AG: – Hem de mantenir una plantilla de treballadors de primera línia.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com