Kyiv Go Meetup Maj 2018:
VĂŠrt: â Hej alle sammen! Tak fordi I er her i dag! Vi har to officielle talere â LjĂžsha og Vania. Der kommer ogsĂ„ to til, hvis vi har tid. FĂžrste taler â Alexey Grachev, han vil fortĂŠlle os om GopherJS.
Alexey Grachev (herefter â AG): â Jeg er Go-udvikler, og jeg skriver webtjenester i Go. Nogle gange skal jeg indblande mig i frontend, og nogle gange mĂ„ jeg selv kaste mig ind i det. Jeg vil dele mine erfaringer og research om Go i frontend.
Legenden er sĂ„dan: FĂžrst taler vi om, hvorfor vi Ăžnsker at kĂžre Go i frontend, derefter diskuterer vi, hvordan det kan gĂžres. Der er to metoder â Web Assembly og GopherJS. Lad os se, hvor disse lĂžsninger stĂ„r, og hvad der kan gĂžres.
Hvad er galt med frontend?
Er alle enige om, at alt er godt med frontend?
Er der fĂ„ tests? Langsom samling? Ăkosystem? Godt.
Jeg kan godt lide en udtalelse fra en af frontend-udviklerne i hans bog:
I Javascript er der ikke noget typesystem. Nu vil jeg nÊvne problemer, jeg har mÞdt undervejs, og forklare, hvordan de hÄndteres.
Man kan overhovedet ikke kalde typesystemet i Javasript for et typesystem â der er strenge, der reprĂŠsenterer objekttypen, men de har faktisk ikke noget at gĂžre med typer. Dette problem er lĂžst i TypeScript (et lag oven pĂ„ Javasript) og Flow (en statisk typechecker for Javascript). GrundlĂŠggende er frontend allerede nĂ„et til en lĂžsning pĂ„ problemet med det dĂ„rlige typesystem i Javascript.
Der findes ikke en standardbibliotek i browseren som sĂ„dan â der er nogle indbyggede objekter og 'magiske' funktioner i browsere. Men jeg mener, at der ikke findes en standardbibliotek i Javascript. Dette problem blev engang lĂžst af jQuery (alle brugte jQuery med alle prototyper, hjĂŠlpere, funktioner der var nĂždvendige for arbejdet). I dag bruger alle Lodash:
Callback hell. Jeg tror, alle har set Javascript kode for omkring 5 Ă„r siden, og det lignede en 'nudel' af et utroligt indviklet netvĂŠrk af callbacks. Denne problematik er nu lĂžst (med introduktionen af ES-15 eller ES-16), da man tilfĂžjede promises til Javascript, og alle fik lettere ved lige i et stykke tid.
Indtil Promice hell kom... Jeg ved ikke, hvordan frontend-industrien formĂ„r det, men de graver hele tiden sig selv ned i underlige afkroge. De fik ogsĂ„ skabt hell med 'promises'. SĂ„ lĂžste de dette problem ved at introducere et nyt primitiv â async/await:
Med asynkronitet er problemet lĂžst. Async/await er en ret populĂŠr konstruktion i forskellige sprog. I Python og andre sprog findes denne tilgang â den er rimeligt god. Problemet er lĂžst.
Hvilket problem er ikke lĂžst? Den geometrisk stigende kompleksitet af rammerne, kompleksiteten af Ăžkosystemet og selve programmerne.
- JavaScripts syntaks er lidt underlig. Vi kender alle problemerne med at addere arrays og objekter og andre mĂŠrkvĂŠrdigheder.
- JavaScript er multiparadigme. Dette er isĂŠr aktuelt nu, hvor Ăžkosystemet er meget stort:
- alle skriver i forskellige stilarter â nogle skriver struktureret, andre skriver funktionelt, forskellige udviklere skriver pĂ„ forskellige mĂ„der;
- fra forskellige pakker (packages) kommer der forskellige paradigmer, nÄr du bruger forskellige pakker;
- der er meget 'sjov' med funktionel programmering i JavaScript â biblioteket Rambda er dukket op, og nu kan ingen lĂŠse programmer skrevet i dette bibliotek.
- Dette bidrager til en stor impact i Þkosystemet, og det er vokset utrolig meget. Pakker er inkompatible med hinanden: nogle er baseret pÄ promises, nogle pÄ async/await, nogle pÄ callbacks. Der skrives ogsÄ i forskellige paradigmer!
- Dette fĂžrer til, at det er svĂŠrt at vedligeholde projekter. Det er svĂŠrt at finde bugs, hvis du ikke kan lĂŠse koden.
Hvad er Web Assembly?
De dygtige folk fra Mozilla Foundation og flere andre virksomheder har opfundet noget, der hedder Web Assembly. Hvad er det?
- Det er en indbygget virtuel maskine i browseren, der understĂžtter et binĂŠrt format.
- Binarprogrammer bliver sendt derhen og kĂžrer nĂŠsten nativt, hvilket betyder, at browseren ikke behĂžver at parse al 'spaghetti' JavaScript-kode hver gang.
- Alle browsere har erklĂŠret stĂžtte.
- Da dette er bytekode, kan der skrives en compiler til ethvert sprog.
- De fire hovedbrowserne leveres allerede med stĂžtte til Web Assembly.
- Snart forventer vi nativer stÞtte i Go. Denne nye arkitektur er allerede tilfÞjet: GOARCH=wasm GOOS=js (snart). Indtil videre, som jeg forstÄr det, er den ikke funktionel, men der er en erklÊring om, at dette helt sikkert vil komme i Go.
Hvad skal vi gĂžre nu? GopherJS
Indtil vi fÄr stÞtte for Web Assembly, er der en transpiler ved navn GopherJS.
- Koden i Go bliver transpilet til 'ren' JavaScript.
- Det kĂžrer i alle browsere â der er ingen nye funktioner, som kun stĂžttes af moderne browsere (det er Vanilla JS, der kĂžrer pĂ„ alt, hvad som helst).
- Der er stĂžtte for nĂŠsten alt, hvad der findes i Go, inklusive gorutiner og kanaler... - alt det, vi elsker og kender.
- NĂŠsten hele standardbiblioteket understĂžttes, med undtagelse af de pakker, der ikke giver mening at understĂžtte i en browser: syscall, net-interaktioner (der er en net/http-klient, men ikke nogen server, og klienten emuleres via XMLHttpRequest). Generelt er hele standardbiblioteket tilgĂŠngeligt - her er det i browseren, her er stdlib Go, som vi elsker.
- Hele Go-pakkeĂžkosystemet, alle tredjepartslĂžsninger (templating osv.) kan kompileres med GopherJS og kĂžres i browseren.
Det er meget nemt at fÄ GopherJS - det er en almindelig Go-pakke. Vi laver go get, og sÄ har vi GopherJS-kommandoen til at bygge applikationen:
Her er et lille hello world...
...En almindelig Go-applikation, det almindelige fmt-pakke fra standardbiblioteket og Binding Js til at tilgÄ browserens API. Println vil i sidste ende blive omdannet til et console log, og browseren vil skrive "Hello gophers"! SÄ nemt: vi laver GopherJS build - kÞrer i browseren - alt fungerer!
Hvad er der lige nu? Bindings
Der er bindings til alle populĂŠre JS-rammevĂŠrk:
- JQuery;
- Angular.js;
- D3.js til graftegning og arbejdet med store data;
- React.js;
- VueJS;
- der er endda stĂžtte for Electron (det vil sige, at vi allerede nu kan skrive desktopapplikationer med "Electron");
- og det mest interessante - det er WebGL (vi kan lave holografiske applikationer, inklusive spil med 3D-grafik, musik og alle funktioner);
- og rigtig mange andre bindings til alle populĂŠre JavaScript-rammevĂŠrk og biblioteker.
Framework
- Der findes allerede en web-ramme specifikt udviklet til GopherJS - Vecty. Det er en fuldgyldig pendant til React.js, men kun udviklet i Go, med specifikationen for GopherJS.
- Der findes endda spilmotorer (overraskende!). Jeg fandt to af de mest populĂŠre:
- Engo;
- Ebiten.
Jeg vil vise et par eksempler pÄ, hvordan det ser ud, og hvad der allerede nu kan skrives i Go:
Eller en sÄdan version (jeg fandt ikke en 3D-skyder, men mÄske findes den):
Hvad foreslÄr jeg?
Lige nu er frontend-industrien i en sÄdan tilstand, at alle sprog, der tidligere har ledet under Javascript, nu vil styrte ind. Nu vil alle blive kompileret til "WebAssembly". Hvad har vi brug for for at fÄ en vÊrdig plads som "gophers" der?
I Go er det traditionelt set, at det er et systemprogrammeringssprog, og der er nĂŠsten ingen biblioteker til UI-arbejde. Der findes noget, men det er halvmorsket og halvdelen ikke-funktionelt.
Og nu har vi et godt tidspunkt til at lave UI-biblioteker i Go, som kan kÞre pÄ GopherJS! Endelig kan vi skrive vores eget framework! Tiden er inde til at skrive et framework, og det vil vÊre et af de fÞrste og fÄ tidlig tilpasning, og du vil vÊre en stjerne (hvis det er et godt framework).
Det er muligt at tilpasse en lang rĂŠkke forskellige pakker, der allerede findes i Go-Ăžkosystemet, til specifikationen i browseren (for eksempel skabelonmotor). De kommer til at fungere, vi kan lave praktiske indpakninger, sĂ„ indhold nemt kan gengives direkte i browseren. Plus, vi kan lave en tjeneste, der kan gengive det samme pĂ„ serveren og frontend'en ved at bruge den samme kode â prĂŠcis som frontend-udviklere Ăžnsker det (men nu i Go).
Vi kan skrive et spil! Just for funâŠ
Det var det for mig.
SpÞrgsmÄl
SpĂžrgsmĂ„l (herefter â S): â Skriver jeg i Go eller Js?
AG: â Du skriver Go-rutiner, kanaler, strukturer, embedding â alt sammen⊠Du tilmelder dig en begivenhed og sender en funktion dertil.
Q: â SĂ„ jeg skriver i »ren« Js?
AG: â Nej, du skriver ligesom i Go og tilslutter dig til browserens API (API'en er forblevet uĂŠndret). Du kan skrive dine egne indpakninger, sĂ„ beskeder kommer ind i kanalen â det er ikke svĂŠrt.
Q: â Hvad med mobil?
AG: â Jeg har helt sikkert set: der er bindinger til Cordova-patch, som Js kĂžrer. I React Native â ved jeg ikke; mĂ„ske er der, mĂ„ske ikke (jeg har ikke interesseret mig sĂ„ meget). Spilmotoren N-go understĂžtter ogsĂ„ mobilapplikationer â bĂ„de iOs og Android.
Q: â SpĂžrgsmĂ„l om Web Assembly. Pladsen bliver mere og mere, pĂ„ trods af komprimering og »zip«... Vil vi ikke drĂŠbe frontend-verdenen endnu mere pĂ„ denne mĂ„de?
AG: â Web Assembly er et binĂŠrt format, og som standard kan binĂŠrt ikke vĂŠre stĂžrre end tekst i den endelige udgivelse... Du har brug for runtime, men det er det samme som at trĂŠkke den standardbibliotek Javascript ind, nĂ„r den ikke er der, derfor bruger vi noget som Lodash. Jeg ved ikke, hvor meget Lodash fylder.
Q: â Tydeligt mindre end runtimeâŠ
AG: â I «rent» Javascript?
Q: â Ja. Vi komprimerer det jo, inden vi sender detâŠ
AG: â Men det er jo tekst⊠Generelt set er en megabyte ret meget, men det er â alt sammen (du har hele runtime). Derefter skriver du din forretningslogik, som vil Ăžge din binary med 1 %. Indtil videre kan jeg ikke se, at det pĂ„virker frontend. Desuden vil Web Assembly kĂžre hurtigere end Javascript af Ă„benlyse grunde â det skal ikke parses.
Q: â Det er stadig et diskussionsemne⊠Der er endnu ikke nogen standardimplementering af "Vasm" (Web Assembly), som gĂžr det muligt at bedĂžmme entydigt. Konceptuelt â ja: vi forstĂ„r alle, at binary skal vĂŠre hurtigere, men den nuvĂŠrende implementering af V8 er meget effektiv.
AG: â Ja.
Q: â Kompileringen fungerer virkelig meget godt, og der er ikke nogen garanti for, at der vil vĂŠre en stor fordel.
AG: â Store drenge arbejder ogsĂ„ med Web Assembly.
Q: â Jeg synes, det er svĂŠrt at dĂžmme om Web Assembly endnu. Der har vĂŠret snak om det i flere Ă„r, men der er ikke mange reelle resultater, der kan mĂŠrkes.
AG: â MĂ„ske. Vi mĂ„ se.
Q: â Vi har ingen problemer pĂ„ backend⊠Skal vi ikke lade disse problemer ligge i frontend? Hvorfor skal vi blande os?
AG: â Vi er nĂždt til at holde et hold af frontend-udviklere.
Lidt reklame đ
Tak fordi du bliver hos os. Kan du lide vores artikler? Ănsker du at se flere interessante materialer? StĂžt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgĂŠngelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! LĂŠs om hvordan
Kilde: habr.com
