Kyiv Go Meetup mai 2018:
moderator: - Hei alle sammen! Takk for at du er her! I dag har vi to offisielle foredragsholdere - Lyosha og Vanya. Det blir to til hvis vi har nok tid. Den første foredragsholderen er Alexey Grachev, han vil fortelle oss om GopherJS.
Alexey Grachev (heretter – AG): – Jeg er en Go-utvikler, og jeg skriver webtjenester i Go. Noen ganger må du forholde deg til frontend, noen ganger må du komme inn i det manuelt. Jeg vil snakke om min erfaring og forskning på Go på frontend.
Legenden er denne: først skal vi snakke om hvorfor vi ønsker å kjøre Go på frontend, så skal vi snakke om hvordan dette kan gjøres. Det er to måter - Web Assembly og GopherJS. La oss se hva statusen til disse løsningene er og hva som kan gjøres.
Hva er galt med frontend?
Er alle enige om at alt er bra med frontend?
Er det ikke nok tester? Treg bygging? Økosystem? Fint.
Når det gjelder frontend, liker jeg sitatet som en av frontend-utviklerne sa i boken sin:
Javascript har ikke et typesystem. Nå skal jeg nevne problemene jeg har møtt i løpet av arbeidet mitt og forklare hvordan de løses.
Typesystemet generelt kan neppe kalles et typesystem i Javasript - det er linjer som indikerer typen av objektet, men faktisk har dette ingenting med typer å gjøre. Dette problemet er løst i TypeScript (et tillegg til Javasript) og Flow (en statisk kontrollør i Javascript). Faktisk har frontend allerede nådd poenget med å løse problemet med et dårlig type system i Javascript.
Det er ikke noe standardbibliotek i nettleseren som sådan - det er noen innebygde objekter og "magiske" funksjoner i nettlesere. Men i Javascript er det ikke noe standardbibliotek som sådan. Dette problemet var allerede løst en gang av jQuery (alle brukte jQuery med alle prototyper, hjelpere, funksjoner som var nødvendig for arbeid). Nå bruker alle Lodash:
Tilbakeringing helvete. Jeg tror alle så Javascript-koden for omtrent 5 år siden, og den så ut som en "nuddel" av en utrolig komplisert tilbakeringing. Nå er dette problemet løst (med utgivelsen av ES-15 eller ES-16), løfter er lagt til Javascript og alle kan puste lettere en stund.
Helt til Promice-helvetet kom... Jeg vet ikke hvordan front-end-industrien klarer seg, men de kjører seg alltid inn i en merkelig jungel. Vi klarte også å gjøre helvete på løfter. Så løste vi dette problemet ved å legge til en ny primitiv - async/await:
Problemet med asynkroni er løst. Async/await er en ganske populær primitiv på forskjellige språk. Python og andre har denne tilnærmingen - den er ganske bra. Problem løst.
Hvilket problem er ikke løst? Den eksponentielt økende kompleksiteten til rammeverk, kompleksiteten til økosystemet og programmene i seg selv.
- Javascript-syntaks er litt merkelig. Vi kjenner alle problemene med å legge til en matrise og et objekt og andre vitser.
- Javascript er multi-paradigme. Dette er et spesielt presserende system nå når økosystemet er veldig stort:
- alle skriver i forskjellige stiler - noen skriver strukturelt, noen skriver funksjonelt, forskjellige utviklere skriver forskjellig;
- fra forskjellige pakker, forskjellige paradigmer når du bruker forskjellige pakker;
- det er mye "moro" med funksjonell programmering i Javasript - rambda-biblioteket dukket opp og nå kan ingen lese programmer skrevet i dette biblioteket.
- Alt dette har stor innvirkning på økosystemet, og det har vokst utrolig. Pakkene er inkompatible med hverandre: noen er basert på løfter, noen er basert på asynkron/avvent, noen er basert på tilbakeringinger. De skriver også i forskjellige paradigmer!
- Dette gjør prosjektet vanskelig å vedlikeholde. Det er vanskelig å finne en feil hvis du ikke kan lese koden.
Hva er Web Assembly?
De modige gutta fra Mozilla Foundation og en rekke andre selskaper kom opp med noe som Web Assembly. Hva er dette?
- Dette er en virtuell maskin innebygd i nettleseren som støtter det binære formatet.
- Binære programmer kommer dit og kjøres nesten naturlig, det vil si at nettleseren ikke trenger å analysere alle "nudlene" med javascript-kode hver gang.
- Alle nettlesere har erklært støtte.
- Siden dette er bytekode, kan du skrive en kompilator for alle språk.
- Fire store nettlesere leveres allerede med Web Assembly-støtte.
- Vi forventer innfødt støtte i Go snart. Denne nye arkitekturen er allerede lagt til: GOARCH=wasm GOOS=js (snart). Så langt, slik jeg forstår det, er det ikke funksjonelt, men det er et utsagn om at det definitivt vil være i Go.
Hva skal jeg gjøre nå? GopherJS
Selv om vi ikke har støtte for Web Assembly, er det en transpiler som GopherJS.
- Go-koden transpileres til "rent" Javascript.
- Kjører i alle nettlesere - det er ingen nye funksjoner som kun støttes av moderne nettlesere (dette er Vanilla JS, som kjører på hva som helst).
- Det er støtte for nesten alt som Go har, inkludert goroutiner og kanaler... alt vi elsker og vet så mye.
- Nesten hele standardbiblioteket støttes, bortsett fra de pakkene som det ikke gir mening å støtte i nettleseren: syscall, net-interaksjoner (det er 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 pakkeøkosystemet i Go, alle tredjepartsløsninger (maler osv.) kan kompileres ved hjelp av GopherJS og kjøres i nettleseren.
GopherJS er veldig enkelt å få tak i – det er bare en vanlig Go-pakke. Vi går og henter, og vi har en GopherJS-kommando for å bygge applikasjonen:
Dette er en så liten hei verden...
...Et vanlig Go-program, en vanlig standard bibliotek fmt-pakke og Binding Js for å nå nettleserens API. Println vil til slutt bli konvertert til konsolllogg og nettleseren vil skrive "Hello gophers"! Så enkelt er det: vi bygger GopherJS – vi lanserer det i nettleseren – alt fungerer!
Hva har du for øyeblikket? Bindinger
Det er bindinger for alle populære js-rammeverk:
- JQuery;
- Angular.js;
- D3.js for plotting og arbeid med big data;
- React.js;
- VueJS;
- det er til og med støtte for Electron (det vil si at vi allerede kan skrive skrivebordsapplikasjoner på Electron);
- og det morsomste er WebGL (vi kan lage fullgrafiske applikasjoner, inkludert spill med 3D-grafikk, musikk og alle godsakene);
- og mange andre bindinger til alle populære javascript-rammeverk og biblioteker.
Rammeverk
- Det er et nettrammeverk som allerede er utviklet spesielt for GopherJS - Vecty. Dette er en fullverdig analog av React.js, men bare utviklet i Go, med spesifikasjonene til GopherJS.
- Det er spillposer (overraskelse!). Jeg fant de to mest populære:
- Engo;
- Ebiten.
Jeg skal vise deg et par eksempler på hvordan det ser ut og hva du allerede kan skrive i Go:
Eller dette alternativet (jeg kunne ikke finne et 3D-skytespill, men kanskje det eksisterer):
Hva tilbyr jeg?
Nå er front-end-industrien i en slik tilstand at alle språkene som tidligere gråt fra Javascript vil skynde seg dit. Nå vil alt bli kompilert i "Web Assemblys". Hva trenger vi for å ta vår rettmessige plass der som gophere?
Go har tradisjonelt antatt at det er et systemprogrammeringsspråk, og det er praktisk talt ingen biblioteker for å jobbe med brukergrensesnittet. Det er noe, men det er halvt forlatt, halvt ikke-funksjonelt.
Og nå er det en god sjanse til å lage UI-biblioteker i Go som vil kjøre på GopherJS! Du kan endelig skrive ditt eget rammeverk! Dette er tiden da du kan skrive et rammeverk, og det vil være et av de første og få tidlig adopsjon, og du vil bli en stjerne (hvis det er et godt rammeverk).
Du kan tilpasse mange forskjellige pakker som allerede er i Go-økosystemet til nettleserens spesifikasjoner (for eksempel Template-motoren). De vil allerede fungere, du kan lage praktiske bindinger slik at du enkelt kan gjengi innholdet direkte i nettleseren. I tillegg kan du lage, for eksempel, en tjeneste som kan gjengi det samme på serveren og på front-end, ved å bruke den samme koden - alt som front-end-utviklere liker (bare nå i Go).
Du kan skrive et spill! Bare for moro skyld…
Det var alt jeg ville si.
spørsmål
Spørsmål (heretter kalt Q): – Skriver jeg i Go eller Js?
AG: – Du skriver rutiner, kanaler, strukturer, embedding – alt i Go... Du abonnerer på et arrangement, sender en funksjon der.
I: – Så jeg skriver i «naken» Js?
AG: – Nei, du skriver som i Go og kobler til nettleserens API (API-en er ikke endret). Du kan skrive dine egne bindinger slik at meldinger sendes til kanalen - det er ikke vanskelig.
I: – Hva med mobilen?
AG: – Jeg så definitivt: det er bindinger for Cordova-lappen som Js kjører. I React Native - jeg vet ikke; kanskje det er det, kanskje ikke (jeg var ikke spesielt interessert). N-go-spillmotoren støtter både mobilapplikasjoner – både iOS og Android.
I: – Spørsmål om Web Assembly. Mer og mer plass blir tatt opp, til tross for komprimering og "zipping"... Vil vi ikke drepe front-end-verdenen på denne måten enda mer?
AG: – Web Assembly er et binært format, og binær som standard kan ikke være i den endelige utgivelsen mer enn tekst... Du trekkes til runtime, men dette er det samme som å dra ut standard Javascript-biblioteket når det ikke er der, så vi bruk litt Lodash. Jeg vet ikke hvor mye Lodash tar.
I: – Tydeligvis mindre enn kjøretid...
AG: – I «rent» Javascript?
I: - Ja. Vi komprimerer den før vi sender den...
AG: – Men dette er tekst... Generelt virker en megabyte som mye, men det er alt (du har hele kjøretiden). Deretter skriver du din egen forretningslogikk, som vil øke din binære med 1%. Så langt ser jeg ikke at dette dreper fronten. Dessuten vil Web Assembly fungere raskere enn Javascript av den åpenbare grunnen - det trenger ikke å analyseres.
I: – Dette er fortsatt et kontroversielt poeng... Det er ennå ikke noen referanseimplementering av «Vasma» (Web Assembly) slik at man kan bedømme entydig. Konseptuelt, ja: vi forstår alle at binær skal være raskere, men den nåværende implementeringen av samme V8 er veldig effektiv.
AG: - Ja.
I: – Samling der fungerer veldig bra, og det er ikke et faktum at det vil være en stor fordel.
AG: – Web Assembly er også laget av store gutter.
I: – Det virker for meg som det fortsatt er vanskelig å dømme Web Assembly. Det har vært samtaler i mange år nå, men det er få reelle prestasjoner som kan merkes.
AG: - Kan være. Vi får se.
I: – We don't have problems on the backend... Kanskje vi burde la disse problemene ligge på frontend? Hvorfor gå dit?
AG: – Vi må beholde en stab av frontlinjearbeidere.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com