Kiev Go Meetup mei 2018:
leidend: - Dag Allemaal! Dank voor uw aanwezigheid! Vandaag hebben we twee officiële sprekers: Lyosha en Vanya. Als we genoeg tijd hebben, volgen er nog twee. De eerste spreker is Alexey Grachev, hij zal ons vertellen over GopherJS.
Alexey Grachev (hierna – AG): – Ik ben een Go-ontwikkelaar en ik schrijf webservices in Go. Soms heb je te maken met de frontend, soms moet je er handmatig induiken. Ik wil het hebben over mijn ervaring en onderzoek naar Go op de frontend.
De legende is deze: eerst zullen we praten over waarom we Go op de frontend willen gebruiken, en daarna zullen we praten over hoe dit kan worden gedaan. Er zijn twee manieren: Web Assembly en GopherJS. Laten we eens kijken wat de status van deze oplossingen is en wat er gedaan kan worden.
Wat is er mis met de frontend?
Is iedereen het erover eens dat alles goed gaat met de frontend?
Zijn er niet genoeg testen? Langzaam opbouwen? Ecosysteem? Prima.
Wat de frontend betreft, vind ik het citaat leuk dat een van de frontend-ontwikkelaars in zijn boek zei:
Javascript heeft geen typesysteem. Nu zal ik de problemen benoemen die ik tijdens mijn werk tegenkwam en uitleggen hoe ze worden opgelost.
Het typesysteem in het algemeen kan in Javascript nauwelijks een typesysteem worden genoemd - er zijn regels die het type van het object aangeven, maar in feite heeft dit niets met typen te maken. Dit probleem is opgelost in TypeScript (een add-on voor Javascript) en Flow (een statische typecontrole in Javascript). Eigenlijk heeft de frontend al het punt bereikt waarop het probleem van een slecht type systeem in Javascript is opgelost.
Er is als zodanig geen standaardbibliotheek in de browser - er zijn enkele ingebouwde objecten en "magische" functies in browsers. Maar in Javascript is er geen standaardbibliotheek als zodanig. Dit probleem is al eens opgelost door jQuery (iedereen gebruikte jQuery met alle prototypes, helpers, functies die nodig waren om te werken). Nu gebruikt iedereen Lodash:
Terugbellen is een hel. Ik denk dat iedereen de Javascript-code ongeveer vijf jaar geleden heeft gezien, en het leek op een “noodle” van een ongelooflijke complexiteit van callbacks. Nu is dit probleem opgelost (met de release van ES-5 of ES-15), zijn er beloftes toegevoegd aan Javascript en kan iedereen even rustiger ademhalen.
Totdat de Promice-hel aanbrak... Ik weet niet hoe de front-end-industrie het doet, maar ze drijven zichzelf altijd in een vreemde jungle. We zijn er ook in geslaagd om beloftes te maken. Vervolgens hebben we dit probleem opgelost door een nieuwe primitief toe te voegen - async/await:
Het probleem met asynchronie is opgelost. Async/await is een redelijk populaire primitief in verschillende talen. Python en anderen hebben deze aanpak: het is best goed. Probleem opgelost.
Welk probleem wordt niet opgelost? De exponentieel toenemende complexiteit van raamwerken, de complexiteit van het ecosysteem en de programma’s zelf.
- Javascript-syntaxis is een beetje vreemd. We kennen allemaal de problemen met het toevoegen van een array en een object en andere grappen.
- Javascript is multi-paradigma. Dit is een bijzonder dringend systeem nu het ecosysteem erg groot is:
- iedereen schrijft in verschillende stijlen - sommigen schrijven structureel, sommigen schrijven functioneel, verschillende ontwikkelaars schrijven op verschillende manieren;
- uit verschillende pakketten, verschillende paradigma's als je verschillende pakketten gebruikt;
- er is veel "plezier" met functioneel programmeren in Javascript - de rambda-bibliotheek verscheen en nu kan niemand programma's lezen die in deze bibliotheek zijn geschreven.
- Dit alles heeft een grote impact op het ecosysteem, en het is ongelooflijk gegroeid. De pakketten zijn niet compatibel met elkaar: sommige zijn gebaseerd op beloftes, sommige zijn gebaseerd op async/await, sommige zijn gebaseerd op callbacks. Ze schrijven ook in verschillende paradigma's!
- Dit maakt het project lastig te onderhouden. Het is moeilijk om een bug te vinden als je de code niet kunt lezen.
Wat is webassemblage?
De dappere jongens van de Mozilla Foundation en een aantal andere bedrijven hebben zoiets als Web Assembly bedacht. Wat is dit?
- Dit is een virtuele machine die in de browser is ingebouwd en die het binaire formaat ondersteunt.
- Binaire programma's komen daar en worden bijna native uitgevoerd, dat wil zeggen dat de browser niet elke keer alle "noedels" van de JavaScript-code hoeft te ontleden.
- Alle browsers hebben ondersteuning verklaard.
- Omdat dit bytecode is, kunt u voor elke taal een compiler schrijven.
- Vier grote browsers worden al geleverd met ondersteuning voor Web Assembly.
- We verwachten binnenkort native ondersteuning in Go. Deze nieuwe architectuur is al toegevoegd: GOARCH=wasm GOOS=js (binnenkort). Voor zover ik het begrijp, is het niet functioneel, maar er is een verklaring dat het zeker in Go zal zijn.
Wat nu te doen? GopherJS
Hoewel we geen ondersteuning hebben voor Web Assembly, is er wel een transpiler zoals GopherJS.
- Go-code wordt omgezet in “puur” Javascript.
- Draait in alle browsers - er zijn geen nieuwe functies die alleen door moderne browsers worden ondersteund (dit is Vanilla JS, die op alles draait).
- Er is ondersteuning voor bijna alles wat Go heeft, inclusief goroutines en kanalen... alles waar we van houden en zoveel weten.
- Bijna de gehele standaardbibliotheek wordt ondersteund, behalve de pakketten waarvoor het geen zin heeft om ze in de browser te ondersteunen: syscall, net-interacties (er is een net/http-client, maar geen server, en de client wordt geëmuleerd via XMLHttpRequest). Over het algemeen is de volledige standaardbibliotheek beschikbaar - hier is het in de browser, hier is Go's stdlib, waar we dol op zijn.
- Het volledige pakket-ecosysteem in Go, alle oplossingen van derden (sjablonen, enz.) kunnen worden gecompileerd met GopherJS en in de browser worden uitgevoerd.
GopherJS is heel gemakkelijk te verkrijgen - het is gewoon een gewoon Go-pakket. We gaan het halen, en we hebben een GopherJS-opdracht om de applicatie te bouwen:
Dit is zo'n kleine hallo wereld...
...Een regulier Go-programma, een regulier standaard bibliotheek-fmt-pakket en Binding Js om de browser-API te bereiken. Println zal uiteindelijk worden geconverteerd naar consolelog en de browser zal “Hallo gophers” schrijven! Zo simpel is het: we doen GopherJS build – we starten het in de browser – alles werkt!
Wat heb je op dit moment? Bindingen
Er zijn bindingen voor alle populaire js-frameworks:
- JQuery;
- Hoekig.js;
- D3.js voor het plotten en werken met big data;
- Reageer.js;
- VueJS;
- er is zelfs ondersteuning voor Electron (dat wil zeggen dat we al desktopapplicaties op Electron kunnen schrijven);
- en het grappigste is WebGL (we kunnen volledig grafische applicaties maken, inclusief games met 3D-graphics, muziek en al het lekkers);
- en vele andere bindingen met alle populaire javascript-frameworks en -bibliotheken.
Achtergrond
- Er is al een webframework speciaal ontwikkeld voor GopherJS - Vecty. Dit is een volwaardige analoog van React.js, maar alleen ontwikkeld in Go, met de specifieke kenmerken van GopherJS.
- Er zijn wildtassen (verrassing!). Ik vond de twee meest populaire:
- Engo;
- Ebiten.
Ik laat je een paar voorbeelden zien van hoe het eruit ziet en wat je al in Go kunt schrijven:
Of deze optie (ik kon geen 3D-shooter vinden, maar misschien bestaat deze wel):
Wat bied ik aan?
Nu verkeert de front-end-industrie in zo'n staat dat alle talen die voorheen uit Javascript riepen, daarheen zullen snellen. Nu wordt alles gecompileerd in “Web Assemblies”. Wat hebben wij nodig om daar als Gophers onze rechtmatige plaats in te nemen?
Go heeft traditioneel aangenomen dat het een systeemprogrammeertaal is en dat er vrijwel geen bibliotheken zijn om met de gebruikersinterface te werken. Er is iets, maar het is half verlaten, half niet-functioneel.
En dit is een goede kans om UI-bibliotheken in Go te maken die op GopherJS draaien! Je kunt eindelijk je eigen raamwerk schrijven! Dit is het moment waarop je een raamwerk kunt schrijven, en het zal een van de eerste zijn die vroegtijdig wordt toegepast, en je zult een ster zijn (als het een goed raamwerk is).
U kunt veel verschillende pakketten die zich al in het Go-ecosysteem bevinden, aanpassen aan de specifieke kenmerken van de browser (bijvoorbeeld de Template-engine). Ze zullen al werken, u kunt handige bindingen maken zodat u de inhoud eenvoudig rechtstreeks in de browser kunt weergeven. Bovendien kun je bijvoorbeeld een service maken die hetzelfde kan weergeven op de server en aan de front-end, met behulp van dezelfde code - alles wat front-end-ontwikkelaars leuk vinden (alleen nu in Go).
Je kunt een spel schrijven! Voor de lol...
Dat is alles.
vragen
Vraag (hierna Q genoemd): – Schrijf ik in Go of Js?
AG: – Je schrijft routines, kanalen, structuren, inbedding – alles in Go... Je abonneert je op een evenement, geeft daar een functie door.
В: – Dus ik schrijf in “naakte” Js?
AG: – Nee, je schrijft alsof je in Go bent en maakt verbinding met de browser-API (de API is niet gewijzigd). Je kunt je eigen bindingen schrijven zodat berichten naar het kanaal worden verzonden - het is niet moeilijk.
В: – Hoe zit het met mobiel?
AG: – Ik heb het zeker gezien: er zijn bindingen voor de Cordova-patch die Js uitvoert. In React Native - ik weet het niet; misschien wel, misschien ook niet (ik was niet bijzonder geïnteresseerd). De N-go game-engine ondersteunt zowel mobiele applicaties - zowel iOS als Android.
В: – Vraag over Web Assembly. Er wordt steeds meer ruimte in beslag genomen, ondanks de compressie en het “zipping”... Zullen we de front-end wereld op deze manier niet nog meer om zeep helpen?
AG: – Web Assembly is een binair formaat, en binair kan standaard niet meer dan tekst in de definitieve release voorkomen... Je voelt je aangetrokken tot runtime, maar dit is hetzelfde als het naar buiten slepen van de standaard Javascript-bibliotheek als deze er niet is, dus we gebruik wat Lodash. Ik weet niet hoeveel Lodash nodig heeft.
В: – Uiteraard minder dan runtime...
AG: – In “puur” Javascript?
В: - Ja. We comprimeren het voordat we het verzenden...
AG: – Maar dit is tekst... Over het algemeen lijkt een megabyte veel, maar dat is alles (je hebt de volledige looptijd). Vervolgens schrijft u uw eigen bedrijfslogica, waardoor uw binaire getal met 1% toeneemt. Tot nu toe zie ik niet dat dit de frontend doodt. Bovendien zal Web Assembly om de voor de hand liggende reden sneller werken dan Javascript: het hoeft niet te worden geparseerd.
В: – Dit is nog steeds een controversieel punt... Er is nog geen referentie-implementatie van “Vasma” (Web Assembly), zodat men ondubbelzinnig kan oordelen. Conceptueel gezien wel: we begrijpen allemaal dat binair sneller moet zijn, maar de huidige implementatie van dezelfde V8 is zeer efficiënt.
AG: - Ja.
В: – Compilatie daar werkt echt heel cool en het is geen feit dat er een groot voordeel zal zijn.
AG: – Web Assembly wordt ook gemaakt door grote jongens.
В: – Het lijkt mij dat het nog steeds moeilijk is om Web Assembly te beoordelen. Er zijn al jaren gesprekken gaande, maar er zijn weinig echte resultaten voelbaar.
AG: - Misschien. We zullen zien.
В: – We hebben geen problemen op de backend... Misschien moeten we deze problemen op de frontend laten? Waarom daarheen gaan?
AG: – We moeten een staf van eerstelijnswerkers behouden.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com