Kyiv Go Meetup maj 2018:
Førende: - Hej alle! Tak fordi du er her! I dag har vi to officielle talere - Lyosha og Vanya. Der kommer to mere, hvis vi har tid. Den første taler er Alexey Grachev, han vil fortælle os om GopherJS.
Alexey Grachev (herefter - AG): – Jeg er Go-udvikler og skriver webtjenester i Go. Nogle gange skal du håndtere frontenden, nogle gange skal du klatre der med håndtag. Jeg vil gerne fortælle om min erfaring og forskning om Go på frontend.
Legenden er denne: Først taler vi om, hvorfor vi vil køre Go på frontend, derefter taler vi om, hvordan vi kan gøre det. Der er to måder - Web Assembly og GopherJS. Lad os se, hvilken tilstand disse beslutninger er i, og hvad der kan gøres.
Hvad er der galt med frontend?
Alle er enige om, at alt er i orden med frontend?
Få tests? Langsom bygning? Økosystem? Bøde.
Med hensyn til frontend kan jeg godt lide et citat, som en af frontend-udviklerne sagde i sin bog:
Javascript har ikke et typesystem. Nu vil jeg nævne de problemer, jeg stødte på i løbet af mit arbejde, og forklare, hvordan de løses.
Typesystemet er generelt svært at kalde et typesystem i Javascript - der er linjer, der angiver typen af et objekt, men det har faktisk ikke noget med typer at gøre. Dette problem er løst i TypeScript (Javascripts tilføjelse) og Flow (Javascripts statiske kontrol af typer). Faktisk er frontenden allerede nået så langt som at løse problemet med et dårligt type system i Javascript.
Der er ikke noget standardbibliotek i browseren som sådan - der er nogle indbyggede objekter og "magiske" funktioner i browsere. Men jeg har ikke et standardbibliotek i Javascript som sådan. Dette problem er allerede løst af jQuery (alle brugte jQuery med alle de prototyper, hjælpere, funktioner, der skulle fungere). Nu bruger alle Lodash:
tilbagekald helvede. Jeg tror, at alle så Javascript-kode for omkring 5 år siden, og det lignede en "nudle" fra en utrolig forvikling af tilbagekald. Nu er dette problem løst (med udgivelsen af ES-15 eller ES-16), løfter blev tilføjet til Javascript, og alle begyndte at trække vejret lettere i et stykke tid.
Indtil Promice-helvede kom... Jeg ved ikke, hvordan front-end-industrien klarer sig, men de kører altid sig selv ind i en eller anden mærkelig jungle. Vi formåede også at gøre helvede på "løfter". Så løste vi dette problem ved at tilføje en ny primitiv - async / await:
Med asynkroni er problemet løst. Async/await er en ret populær primitiv på forskellige sprog. Python og andre har denne tilgang – den er god nok. Problem løst.
Hvilket problem er ikke løst? Den eksponentielt stigende kompleksitet af rammer, kompleksiteten af økosystemet og selve programmerne.
- Javascripts syntaks er lidt mærkelig. Vi kender alle problemerne med at tilføje et array og et objekt og andre tricks.
- Javascript er multiparadigme. Nu er dette et særligt presserende system, når økosystemet er meget stort:
- alle skriver i forskellige stilarter - nogen skriver strukturelt, nogen skriver funktionelt, forskellige udviklere skriver forskelligt;
- fra forskellige pakker (pakker) forskellige paradigmer, når du bruger forskellige pakker;
- en masse "sjov" med funktionel programmering i Javascript - rambda-biblioteket dukkede op og nu kan ingen læse programmer skrevet i dette bibliotek.
- Alt dette har stor indflydelse på økosystemet, og det er vokset utroligt. Pakkerne er inkompatible med hinanden: nogle er på løfter, nogle er på async/afventer, nogle er på tilbagekald. De skriver også i forskellige paradigmer!
- Det gør projektet svært at vedligeholde. Det er svært at finde en fejl, hvis du ikke kan læse koden.
Hvad er Web Assembly?
De modige fyre fra Mozilla Foundation og en række andre virksomheder fandt på sådan noget som Web Assembly. Hvad er dette?
- Dette er en virtuel maskine indbygget i browseren, der understøtter det binære format.
- Binære programmer kommer dertil, de udføres næsten native, det vil sige, at browseren ikke behøver at parse alle "nudler" i javascript-koden hver gang.
- Alle browsere har erklæret support.
- Da dette er bytekode, kan du skrive en compiler til ethvert sprog.
- De fire store browsere leveres allerede med Web Assembly-understøttelse.
- Vi forventer snart indbygget support i Go. Denne nye arkitektur er allerede blevet tilføjet: GOARCH=wasm GOOS=js (snart). Så vidt jeg forstår det er den ikke funktionel, men der er en erklæring om, at den helt sikkert vil være i Go.
Hvad skal jeg gøre nu? GopherJS
Selvom vi ikke har Web Assembly-understøttelse, er der en transpiler som GopherJS.
- Go-koden transpileres til "ren" Javascript.
- Kører i alle browsere - der er ingen nye funktioner, der kun understøttes af moderne browsere (dette er Vanilla JS, som kører på hvad som helst).
- Der er support til næsten alt, hvad der er i Go, inklusive goroutiner og kanaler ... - alt det, vi elsker og ved så meget.
- Næsten hele standardbiblioteket er understøttet, med undtagelse af de pakker, som det ikke giver mening at understøtte i browseren: syscall, net-interaktioner (der er en net / http-klient, men ingen server, og klienten emuleres via XMLHttpRequest) . Generelt er hele standardbiblioteket tilgængeligt - her er det i browseren, her er Go stdlib, som vi elsker.
- Hele pakke-økosystemet i Go, alle tredjepartsløsninger (skabelon osv.) kan kompileres med GopherJS og køres i browseren.
Det er meget nemt at få GopherJS - det er bare en almindelig Go-pakke. Vi gør en go get, og vi har en GopherJS kommando til at bygge applikationen:
Her er sådan en lille hej verden...
... Et almindeligt Go-program, en almindelig fmt-pakke af standardbiblioteket og Binding Js for at nå browser-API'en. Println vil til sidst blive konverteret til konsollog, og browseren vil skrive "Hej gophers"! Det er så enkelt: vi laver GopherJS build - vi starter det i browseren - alt virker!
Hvad er der i øjeblikket? Indbindinger
Der er bindinger til alle populære js-frameworks:
- jquery;
- Angular.js
- D3.js til at plotte og arbejde med big data;
- React.js
- VueJS;
- der er endda understøttelse af Electron (det vil sige, vi kan allerede skrive desktop-applikationer på Electron);
- og det sjoveste er WebGL (vi kan lave fuldgrafiske applikationer, inklusive spil med 3D-grafik, musik og alt det gode);
- og en masse andre bindinger til alle populære javascript-frameworks og biblioteker.
Framework
- Der er allerede en webramme udviklet specifikt til GopherJS - Vecty. Dette er en fuldgyldig analog af React.js, men kun udviklet i Go, med detaljerne i GopherJS.
- Der er spiltasker (pludselig!). Jeg fandt to af de mest populære:
- engo;
- Ebiten.
Jeg vil demonstrere et par eksempler på, hvordan det ser ud, og hvad der allerede kan skrives i Go:
Eller denne mulighed (jeg fandt ikke et 3D-skydespil, men måske findes det):
Hvad foreslår jeg?
Nu er front-end-industrien i en sådan tilstand, at alle de sprog, der tidligere råbte fra Javascript, vil skynde sig dertil. Nu vil alt kompileres til "Web Assemblys". Hvad har vi brug for for at tage en værdig plads der som "gophers"?
I Go er det traditionelt gået, at det er et systemprogrammeringssprog, og der er praktisk talt ingen biblioteker til at arbejde med brugergrænsefladen. Der er noget, men det er halvt forladt, halvt ikke-funktionelt.
Og nu - en god chance for at lave UI-biblioteker i Go, der kører på GopherJS! Du kan endelig skrive din egen ramme! Tiden er kommet, hvor du kan skrive en ramme, og den bliver en af de første og bliver adopteret tidligt, og du bliver en stjerne (hvis det er en god ramme).
Du kan tilpasse en masse forskellige pakker, der allerede findes i Go-økosystemet, til browserens specifikationer (f.eks. skabelonmotoren). De vil allerede virke, du kan lave praktiske bindinger, så du nemt kan gengive indhold direkte i browseren. Plus, du kan for eksempel lave en tjeneste, der kan gengive det samme på serveren og på front-end, ved hjælp af den samme kode - alt det, front-end-udviklere kan lide (kun nu på Go).
Du kan skrive et spil! Bare for sjov…
Det var alt, jeg ville sige.
R'RѕRїSЂRѕSЃS <
Spørgsmål (i det følgende benævnt Q): – Skriver jeg i Go eller Js?
AG: – Du skriver rutiner, kanaler, strukturer, indlejring – alt i Go... Du abonnerer på en begivenhed, sender en funktion der.
I: - Det vil sige, jeg skriver på de "nøgne" Js?
AG: - Nej, du skriver som i Go og opretter forbindelse til browser-API'en (API'en er ikke ændret). Du kan skrive dine egne bindinger, så der kommer beskeder til kanalen – det er ikke svært.
I: - Hvad med mobilen?
AG: - Jeg så med sikkerhed: Der er bindere til Cordova-patchen, som Js lancerer. I React Native ved jeg det ikke; måske er der, måske ikke (ikke specielt interesseret). N-go spilmotoren understøtter både mobilapplikationer – både iOS og Android.
I: – Et spørgsmål om Web Assembly. Flere og flere steder bliver besat, på trods af kortfattetheden, "zipping" ... Vil vi ikke dræbe frontendens verden endnu mere på denne måde?
AG: - Web Assembly er et binært format, og standard binær kan ikke være større end tekst i den endelige udgivelse ... Du trækkes af runtime, men det er det samme som at trække i Javascript standardbiblioteket, når det ikke er der, så vi brug noget Lodash. Jeg ved ikke, hvor lang tid Lodash tager.
I: - Åbenbart mindre end køretid ...
AG: - På "ren" Javascript?
I: - Ja. Vi komprimerer det, før vi sender det...
AG: - Men det er tekst ... Generelt er en megabyte ligesom meget, men det er alt (du har hele kørselstiden). Dernæst skriver du din egen forretningslogik, der vil øge din binære med 1%. Indtil videre kan jeg ikke se, at det dræber frontenden. Desuden vil Web Assembly arbejde hurtigere end Javascript af den indlysende årsag - det behøver ikke at blive parset.
I: - Indtil videre en kontroversiel pointe ... Der er stadig ingen referenceimplementering af "Wasma" (Web Assembly), så man entydigt kan bedømme. Konceptuelt, ja: vi forstår alle, at binær skal være hurtigere, men den nuværende implementering af den samme V8 er meget effektiv.
AG: - Ja.
I: - Kompilering der fungerer virkelig meget fedt, og det er ikke et faktum, at der vil være en stor fordel.
AG: - Web Assembly laves også af store fyre.
I: - Indtil videre, forekommer det mig, er det stadig svært at bedømme Web Assembly. I mange år har der været samtaler, men der er få reelle resultater, der kan mærkes.
AG: - Måske. Lad os se.
I: – Vi har ikke problemer på backend... Måske skulle vi lade disse problemer ligge i frontend? Hvorfor gå derhen?
AG: - Vi skal beholde staben af frontliners.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com