Kyiv Go Meetup May 2018:
Moderator: â Hello everyone! Thank you for coming! Today we have two official speakers â Lesha and Vanya. There will be two more if we have time. The first speaker is Alexey Grachev, who will tell us about GopherJS.
Alexey Grachev (hereafter â AG): â I am a Go developer, and I write web services in Go. Sometimes I have to deal with frontend, and occasionally I dive into it myself. I want to share my experience and research on Go in frontend.
The legend goes: first, we will discuss why we want to run Go on the frontend, then we will talk about how to do it. There are two ways â Web Assembly and GopherJS. Let's see the current state of these solutions and what can be done.
What's wrong with the frontend?
Does everyone agree everything is fine with the frontend?
Not enough tests? Slow builds? Ecosystem issues? Good.
Regarding the frontend, I like the quote by a frontend developer in his book:
JavaScript lacks a type system. Now I will name the problems I faced during my work and explain how they are solved.
It's hard to even call it a type system in JavaScript â there are strings that denote the type of an object, but they don't really relate to types at all. This problem is solved in TypeScript (a superset of JavaScript) and Flow (a static type checker for JavaScript). Frontend has already reached a solution for the poor type system in JavaScript.
There is no standard library in the browser as such â there are some built-in objects and 'magical' functions in browsers. But in JavaScript, there isn't a standard library. This problem was once solved by jQuery (everyone used jQuery with all its prototypes, helpers, and functions needed for work). Now everyone uses Lodash:
Callback hell. I think everyone has seen JavaScript code from about 5 years ago, and it looked like a 'noodle' of incredibly convoluted callbacks. This problem has been solved (with the release of ES-15 or ES-16); promises were added to JavaScript, and everyone could breathe a little easier for a while.
Until Promise hell came⊠I don't know how the frontend industry manages, but they always get themselves into strange depths. They've managed to create a hell with 'promises'. Then they decided to solve this problem by adding a new primitive â async/await:
Problemet med asynkronitet er lĂžst. Async/await er en populĂŠr primitiv i forskellige sprog. Der er en sĂ„dan tilgang i Python og andre sprog â den er ganske god. Problemet er lĂžst.
Hvilket problem er ikke lĂžst? Den stigende kompleksitet af rammer, kompleksiteten af Ăžkosystemet og selve programmerne.
- JavaScript-syntaksen er lidt mĂŠrkelig. Vi kender alle problemerne med at summere et array og et objekt og andre sjove ting.
- JavaScript er multiparadigmatisk. Det er isĂŠr relevant nu, hvor Ăžkosystemet er meget stort:
- alle skriver pĂ„ forskellige mĂ„der â nogle skriver strukturelt, nogle skriver funktionelt, forskellige udviklere skriver forskelligt;
- fra forskellige pakker er 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 med dette bibliotek.
- Dette bidrager til en stor impact i Þkosystemet, og det er vokset utrolig meget. Pakker er ikke kompatible med hinanden: nogle er baseret pÄ promises, nogle pÄ async/await, nogle pÄ callbacks. De skriver ogsÄ i forskellige paradigmer!
- Dette fĂžrer til, at det er svĂŠrt at vedligeholde projektet. 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 har opfundet noget kaldet Web Assembly. Hvad er det?
- Det er en indbygget virtuel maskine i browseren, der understĂžtter binĂŠrt format.
- BinĂŠre programmer kan komme ind, og de udfĂžres nĂŠsten natuligt, hvilket betyder, at browseren ikke behĂžver at parse al 'nudlerne' af JavaScript-koden hver gang.
- Alle browsere har erklĂŠret stĂžtte.
- Da det er bytecode, kan du skrive en compiler til ethvert sprog.
- De fire stĂžrste browsere leveres allerede med stĂžtte til Web Assembly.
- Snart forventer vi nativ stÞtte i Go. En ny arkitektur er allerede blevet tilfÞjet: GOARCH=wasm GOOS=js (snart). Indtil videre, som jeg forstÄr det, er det ikke funktionelt, men der er erklÊringer om, at det helt klart vil vÊre i Go.
Hvad skal man gĂžre nu? GopherJS
Da vi ikke har stĂžtte til Web Assembly, er der en transpiler kaldet GopherJS.
- Kode i Go 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, der kan kĂžre overalt).
- Det er stĂžtte for nesten alt som finnes i Go, inkludert gorutiner og kanaler⊠â alt vi elsker og kjenner til.
- Nesten hele standardbiblioteket stĂžttes, bortsett fra de pakkene som ikke gir mening Ă„ stĂžtte i nettleseren: syscall, nettverksinteraksjoner (det finnes en net/http-klient, men ingen server, og klienten emuleres via XMLHttpRequest). Generelt er hele standardbiblioteket tilgjengelig â her er det i nettleseren, her er stdlib Go, som vi elsker.
- Hele Ăžkosystemet av pakker i Go, alle tredjepartslĂžsninger (malver osv.) kan kompileres med GopherJS og kjĂžres i nettleseren.
Det er veldig enkelt Ă„ skaffe GopherJS â det er en vanlig Go-pakke. Vi kjĂžrer go get, og vi har GopherJS-kommandoen for Ă„ bygge applikasjonen:
Her er et lite hello worldâŠ
âŠEn vanlig Go-program, vanlig pakke fmt fra standardbiblioteket og Binding JS, for Ă„ nĂ„ ut til nettleserens API. Println vil til slutt bli konvertert til console log og nettleseren vil skrive "Hello gophers"! SĂ„ enkelt: vi gjĂžr GopherJS build â kjĂžrer det i nettleseren â alt fungerer!
Hva er tilgjengelig pÄ nÄvÊrende tidspunkt? Bindings
Det finnes bindings for alle populĂŠre js-rammeverk:
- JQuery;
- Angular.js;
- D3.js for grafikk og arbeid med store data;
- React.js;
- VueJS;
- Det finnes til og med stÞtte for Electron (det vil si at vi allerede nÄ kan skrive skrivebordsapplikasjoner med "Electron");
- og det mest interessante â er WebGL (vi kan lage holografiske applikasjoner, inkludert spill med 3D-grafikk, musikk og alle de fine tingene);
- og mange flere bindings for alle populĂŠre JavaScript-rammeverk og biblioteker.
Rammeverk
- Det er utviklet et web-rammeverk spesielt for GopherJS â Vecty. Det er et fullt fungerende alternativ til React.js, men bare utviklet pĂ„ Go, med spesifikasjoner for GopherJS.
- Det finnes spillrammer (overraskende!). Jeg fant to av de mest populĂŠre:
- Engo;
- Ebiten.
Jeg vil vise et par eksempler pÄ hvordan det ser ut og hva som allerede kan skrives i Go:
Eller et annet alternativ (jeg fant ingen 3D-skytespill, men kanskje det finnes):
Hva foreslÄr jeg?
NÄvÊrende tilstand av frontend-industrien er slik at alle sprÄk som tidligere har klaget over Javascript, nÄ vil strÞmme inn. NÄ vil allt kompileres til "Web Assembly". Hva trenger vi for Ä ta en respektabel plass der som "gophers"?
I Go er tradisjonelt ansett som et systemprogrammeringssprÄk, og det finnes praktisk talt ingen biblioteker for Ä jobbe med UI. Det finnes noe, men det er delvis forlatt og delvis ikke-funksjonelt.
Og nÄ har vi en god mulighet til Ä lage UI-biblioteker pÄ Go som kan kjÞres pÄ GopherJS! Vi kan endelig skrive vÄrt eget rammeverk! Tiden er inne for Ä utvikle et rammeverk som vil vÊre blant de fÞrste og fÄ tidlig adopsjon, og du vil bli en stjerne (hvis det er et godt rammeverk).
Man kan tilpasse mange forskjellige pakker som allerede eksisterer i Go-Ăžkosystemet til spesifikasjonene til nettleseren (for eksempel, malmotor). De vil allerede fungere, og vi kan lage komfortable innpakninger for Ă„ enkelt gjengi innhold direkte i nettleseren. I tillegg kan vi lage en tjeneste som kan gjengi det samme bĂ„de pĂ„ serveren og pĂ„ frontenden, ved Ă„ bruke den samme koden â akkurat som frontend-utviklere liker det (bare nĂ„ pĂ„ Go).
Vi kan lage et spill! Bare for moro...
Jeg er ferdig.
SpÞrsmÄl
SpĂžrsmĂ„l (senere â S): â Skriver jeg pĂ„ Go eller pĂ„ Js?
AG: â Du skriver pĂ„ Go rutiner, kanaler, strukturer, innkapsling â alt... Du abonnerer pĂ„ en hendelse, og sender en funksjon dit.
Q: â SĂ„ jeg skriver pĂ„ «ren» Js?
AG: â Nei, du skriver egentlig pĂ„ Go og kobler deg til nettleserens API (API-et har ikke endret seg). Du kan lage dine egne innpakninger slik at meldinger kommer inn i kanalen â det er ikke sĂ„ vanskelig.
Q: â Hva med mobil?
AG: â Jeg har definitivt sett: det finnes bindinger for Cordova, som Js kjĂžrer. NĂ„r det gjelder React Native â jeg vet ikke; det kan eksistere, eller det kan ikke (jeg har ikke interessert meg for det). Spillmotoren N-go stĂžtter bĂ„de mobilapplikasjoner â bĂ„de iOS og Android.
Q: â SpĂžrsmĂ„l om WebAssembly. Plass kreves mer og mer, til tross for komprimering og «zipede»... Vil vi ikke pĂ„ denne mĂ„ten Ăždelegge frontend-verdenen enda mer?
AG: â WebAssembly er et binĂŠrt format, og et binĂŠrt format kan per definisjon ikke vĂŠre stĂžrre enn teksten i den endelige utgaven... Du lengter etter runtime, men det er det samme som Ă„ dra inn JavaScripts standardbibliotek nĂ„r det ikke finnes, derfor bruker vi noe som Lodash. Jeg vet ikke hvor mye Lodash tar opp.
Q: â Ă penbart mindre enn runtime...
AG: â PĂ„ «ren» Javascript?
Q: â Ja. Vi komprimerer det fĂžr vi sender det...
AG: â Men det er jo tekst⊠Generelt er megabyte mye, men det er alt (du har hele runtime tilgjengelig). Deretter skriver du din forretningslogikk, som vil Ăžke binĂŠret ditt med 1 %. SĂ„ langt ser jeg ikke noe som vil drepe frontenden. Dessuten vil Web Assembly kjĂžre raskere enn Javascript av Ă„penbare grunner â det mĂ„ ikke parses.
Q: â Det er fortsatt et omdiskutert punkt⊠Det finnes ennĂ„ ikke en standard implementering av «Vasm» (Web Assembly), sĂ„ vi kan ikke bedĂžmme entydig. Konseptuelt â ja: vi forstĂ„r alle at binĂŠret mĂ„ vĂŠre raskere, men nĂ„vĂŠrende implementering av V8 er veldig effektiv.
AG: â Ja.
Q: â Kompileringen der fungerer faktisk veldig bra, og det er ikke sikkert at det vil vĂŠre en stor fordel.
AG: â Web Assembly blir ogsĂ„ laget av store aktĂžrer.
Q: â For nĂ„ virker det som det fortsatt er vanskelig Ă„ bedĂžmme Web Assembly. Det har vĂŠrt snakk om det i Ă„revis, men det er fĂ„ reelle fremskritt som kan tas pĂ„.
AG: â Kanskje. Vi fĂ„r se.
Q: â Vi har ingen problemer pĂ„ baksiden⊠Skal vi kanskje la disse problemene ligge pĂ„ frontenden? Hvorfor blande seg inn?
AG: â Vi mĂ„ holde et team av frontendere.
Litt reklame đ
Takk for at du er med oss. Liker du artiklene vĂ„re? Ănsker du Ă„ se mer interessant materiale? StĂžtt oss ved Ă„ legge inn en bestilling eller ved Ă„ anbefale oss til kjente, , en unik alternativ til entry-level servere, som vi har laget for deg: (tilgjengelige alternativer med RAID1 og RAID10, opptil 24 kjerner og opptil 40GB DDR4).
Dell R730xd er 2 ganger billigere i Equinix Tier IV datasenteret i Amsterdam? Bare hos oss i Nederland! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â fra $99! Les om hvordan
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish