Kyiv Go Meetup maj 2018:
Ledande: - Hej alla! Tack för att du finns här! Idag har vi två officiella talare - Lyosha och Vanya. Det blir två till om vi har tillräckligt med tid. Den första talaren är Alexey Grachev, han kommer att berätta om GopherJS.
Alexey Grachev (nedan – AG): – Jag är en Go-utvecklare och skriver webbtjänster i Go. Ibland måste du ta itu med frontend, ibland måste du komma in i det manuellt. Jag vill prata om min erfarenhet och forskning om Go på frontend.
Legenden är denna: först ska vi prata om varför vi vill köra Go på frontend, sedan ska vi prata om hur detta kan göras. Det finns två sätt - Web Assembly och GopherJS. Låt oss se vad statusen för dessa lösningar är och vad som kan göras.
Vad är det för fel på fronten?
Håller alla med om att allt är bra med frontend?
Finns det inte tillräckligt med tester? Långsam konstruktion? Ekosystem? Bra.
Angående frontend, jag gillar citatet som en av frontend-utvecklarna sa i sin bok:
Javascript har inget typsystem. Nu ska jag namnge de problem som jag stött på under mitt arbete och förklara hur de löses.
Typsystemet kan knappast kallas ett typsystem i Javasript - det finns linjer som indikerar typen av objekt, men i själva verket har detta inget med typer att göra. Det här problemet är löst i TypeScript (ett tillägg till Javasript) och Flow (en statisk checker i Javascript). Egentligen har frontend redan nått punkten att lösa problemet med ett dåligt system i Javascript.
Det finns inget standardbibliotek i webbläsaren som sådan - det finns några inbyggda objekt och "magiska" funktioner i webbläsare. Men i Javascript finns det inget standardbibliotek som sådant. Detta problem löstes redan en gång av jQuery (alla använde jQuery med alla prototyper, hjälpare, funktioner som behövdes för att fungera). Nu använder alla Lodash:
Återuppringning helvete. Jag tror att alla såg Javascript-koden för ungefär 5 år sedan, och det såg ut som en "nudel" av en otrolig krånglighet av återuppringningar. Nu har detta problem lösts (med lanseringen av ES-15 eller ES-16), löften har lagts till i Javascript och alla kan andas lättare ett tag.
Tills Promice-helvetet kom... Jag vet inte hur front-end-industrin klarar sig, men de kör sig alltid in i någon konstig djungel. Vi lyckades också göra helvete på löften. Sedan löste vi detta problem genom att lägga till en ny primitiv - async/await:
Problemet med asynkroni är löst. Async/await är en ganska populär primitiv på olika språk. Python och andra har detta tillvägagångssätt - det är ganska bra. Problemet löst.
Vilket problem är inte löst? Ramverkens exponentiellt ökande komplexitet, ekosystemets komplexitet och själva programmen.
- Javascript-syntax är lite konstig. Vi känner alla till problemen med att lägga till en array och ett objekt och andra skämt.
- Javascript är multiparadigm. Detta är ett särskilt pressande system nu när ekosystemet är mycket stort:
- alla skriver i olika stilar - vissa skriver strukturellt, vissa skriver funktionellt, olika utvecklare skriver på olika sätt;
- från olika paket, olika paradigm när du använder olika paket;
- det finns mycket "roligt" med funktionell programmering i Javasript - rambda-biblioteket dök upp och nu kan ingen läsa program skrivna i detta bibliotek.
- Allt detta har stor inverkan på ekosystemet, och det har vuxit otroligt. Paketen är inkompatibla med varandra: vissa är baserade på löften, vissa är baserade på asynkron/avvaktar, vissa är baserade på återuppringningar. De skriver också i olika paradigm!
- Detta gör projektet svårt att underhålla. Det är svårt att hitta en bugg om du inte kan läsa koden.
Vad är Web Assembly?
De modiga killarna från Mozilla Foundation och ett antal andra företag kom på en sådan sak som Web Assembly. Vad är detta?
- Detta är en virtuell maskin inbyggd i webbläsaren som stöder det binära formatet.
- Binära program kommer dit och exekveras nästan inbyggt, det vill säga webbläsaren behöver inte analysera alla "nudlar" med javascript-kod varje gång.
- Alla webbläsare har deklarerat stöd.
- Eftersom detta är bytekod kan du skriva en kompilator för vilket språk som helst.
- Fyra stora webbläsare levereras redan med stöd för Web Assembly.
- Vi förväntar oss inbyggt stöd i Go snart. Denna nya arkitektur har redan lagts till: GOARCH=wasm GOOS=js (snart). Så långt som jag förstår det är det inte funktionellt, men det finns ett uttalande om att det definitivt kommer att finnas i Go.
Vad ska man göra nu? GopherJS
Även om vi inte har stöd för Web Assembly, finns det en transpiler som GopherJS.
- Go-koden transpileras till "rent" Javascript.
- Körs i alla webbläsare - det finns inga nya funktioner som endast stöds av moderna webbläsare (detta är Vanilla JS, som körs på vad som helst).
- Det finns stöd för nästan allt som Go har, inklusive goroutiner och kanaler... allt vi älskar och vet så mycket.
- Nästan hela standardbiblioteket stöds, förutom de paket som det inte är meningsfullt att stödja i webbläsaren: syscall, net-interaktioner (det finns en net/http-klient, men ingen server, och klienten emuleras via XMLHttpRequest). I allmänhet är hela standardbiblioteket tillgängligt – här finns det i webbläsaren, här är Gos stdlib, som vi älskar.
- Hela paketekosystemet i Go, alla tredjepartslösningar (mallar etc.) kan kompileras med GopherJS och köras i webbläsaren.
GopherJS är väldigt lätt att få – det är bara ett vanligt Go-paket. Vi går och hämtar, och vi har ett GopherJS-kommando för att bygga applikationen:
Det här är en så liten hej värld...
...Ett vanligt Go-program, ett vanligt standardbibliotek fmt-paket och Binding Js för att nå webbläsarens API. Println kommer så småningom att konverteras till konsollogg och webbläsaren kommer att skriva "Hello gophers"! Så enkelt är det: vi bygger GopherJS – vi lanserar det i webbläsaren – allt fungerar!
Vad har du för tillfället? Bindningar
Det finns bindningar för alla populära js-ramverk:
- JQuery;
- Angular.js;
- D3.js för att plotta och arbeta med big data;
- React.js;
- VueJS;
- det finns till och med stöd för Electron (det vill säga vi kan redan skriva skrivbordsapplikationer på Electron);
- och det roligaste är WebGL (vi kan göra fullgrafiska applikationer, inklusive spel med 3D-grafik, musik och alla godsaker);
- och många andra bindningar till alla populära javascript-ramverk och bibliotek.
Ramverk
- Det finns ett webbramverk som redan utvecklats specifikt för GopherJS - Vecty. Detta är en fullfjädrad analog av React.js, men endast utvecklad i Go, med specifikationerna för GopherJS.
- Det finns spelväskor (överraskning!). Jag hittade de två mest populära:
- Engo;
- Ebiten.
Jag ska visa dig ett par exempel på hur det ser ut och vad du redan kan skriva i Go:
Eller det här alternativet (jag kunde inte hitta en 3D-shooter, men det kanske finns):
Vad erbjuder jag?
Nu är front-end-branschen i ett sådant tillstånd att alla språk som tidigare grät från Javascript kommer att rusa dit. Nu kommer allt att sammanställas till "Web Assemblys". Vad behöver vi för att ta vår rättmätiga plats där som gophers?
Go har traditionellt antagit att det är ett systemprogrammeringsspråk, och det finns praktiskt taget inga bibliotek för att arbeta med användargränssnittet. Det finns något, men det är halvt övergivet, halvt icke-funktionellt.
Och nu finns en bra chans att skapa UI-bibliotek i Go som kommer att köras på GopherJS! Äntligen kan du skriva din egen ram! Det här är tiden då du kan skriva ett ramverk, och det kommer att vara ett av de första och få tidig adoption, och du kommer att bli en stjärna (om det är ett bra ramverk).
Du kan anpassa många olika paket som redan finns i Go-ekosystemet till webbläsarens specifikation (till exempel Template-motorn). De kommer redan att fungera, du kan göra bekväma bindningar så att du enkelt kan rendera innehållet direkt i webbläsaren. Dessutom kan du till exempel skapa en tjänst som kan rendera samma sak på servern och på front-end, med samma kod - allt som front-end-utvecklare gillar (endast nu i Go).
Du kan skriva ett spel! För skojs skull…
Det var allt jag ville säga.
frågor
Fråga (nedan kallad Q): – Skriver jag i Go eller Js?
AG: – Du skriver rutiner, kanaler, strukturer, inbäddning – allt i Go... Du prenumererar på ett event, passerar en funktion där.
PÅ: – Så jag skriver i "nakna" Js?
AG: – Nej, du skriver som i Go och ansluter till webbläsarens API (API:t har inte ändrats). Du kan skriva dina egna bindningar så att meddelanden skickas till kanalen - det är inte svårt.
PÅ: – Hur är det med mobilen?
AG: – Jag såg definitivt: det finns bindningar för Cordova-lappen som Js kör. In React Native - jag vet inte; kanske finns det, kanske inte (jag var inte särskilt intresserad). N-go-spelmotorn stöder både mobilapplikationer – både iOS och Android.
PÅ: – Fråga om Web Assembly. Mer och mer plats tas upp, trots komprimeringen och "zipningen"... Kommer vi inte att döda front-end-världen på detta sätt ännu mer?
AG: – Web Assembly är ett binärt format, och binär som standard kan inte finnas i den slutliga versionen mer än text... Du dras till runtime, men det är samma sak som att dra ut standard Javascript-biblioteket när det inte finns där, så vi använd lite Lodash. Jag vet inte hur mycket Lodash tar.
PÅ: – Uppenbarligen mindre än körtid...
AG: – I "rent" Javascript?
PÅ: - Ja. Vi komprimerar den innan vi skickar den...
AG: – Men det här är text... I allmänhet verkar en megabyte vara mycket, men det är allt (du har hela körtiden). Därefter skriver du din egen affärslogik, vilket kommer att öka din binära med 1%. Än så länge ser jag inte att detta dödar fronten. Dessutom kommer Web Assembly att fungera snabbare än Javascript av den uppenbara anledningen - det behöver inte tolkas.
PÅ: – Detta är fortfarande en kontroversiell punkt... Det finns ännu inte någon referensimplementering av "Vasma" (Web Assembly) så att man kan bedöma entydigt. Konceptuellt, ja: vi förstår alla att binärt bör vara snabbare, men den nuvarande implementeringen av samma V8 är mycket effektiv.
AG: - Ja.
PÅ: – Sammanställning där fungerar verkligen väldigt coolt och det är inte ett faktum att det kommer att vara en stor fördel.
AG: – Web Assembly görs också av stora killar.
PÅ: – Jag tycker att det fortfarande är svårt att bedöma Web Assembly. Det har varit samtal i många år nu, men det är få verkliga prestationer som går att känna.
AG: - Kanske. Vi får se.
PÅ: – We don't have problems on the backend... Kanske borde vi lämna dessa problem på frontend? Varför åka dit?
AG: – Vi måste behålla en stab av frontlinjearbetare.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com