Alexey Grachev: Go Frontend

Kyiv Go Meetup maj 2018:

Presentatör: – Hej alla! Tack för att ni är här! Idag har vi två officiella talare – Lyosha och Vanya. Det kommer att bli två till om vi har tid. Första talaren är Alexey Grachev, som kommer att berätta om GopherJS.

Alexey Grachev (hädanefter – AG): – Jag är Go-utvecklare och jag skriver webbservrar i Go. Ibland måste jag handskas med frontend, ibland går jag in där med händerna. Jag vill berätta om mina erfarenheter och forskningar kring Go på frontend.

Legenden säger: först ska vi prata om varför vi vill köra Go på frontend, sedan ska vi prata om hur vi kan göra det. Det finns två sätt – WebAssembly och GopherJS. Låt oss se i vilket skick dessa lösningar är och vad som kan göras.

Vad är fel med frontend?

Är alla överens om att allt är bra med frontend?

För få tester? Långsam byggprocess? Ekosystem? Bra.

När det gäller frontend gillar jag ett citat från en av frontend-utvecklarna i hans bok:

I Javascript finns det inget typ-system. Nu kommer jag att nämna problem som jag har stött på under mitt arbete och förklara hur de löses.

Ett typ-system är egentligen svårt att kalla ett typ-system i Javascript – det finns strängar som representerar objekttypen, men det har egentligen ingenting med typer att göra. Detta problem har lösts i TypeScript (en överbyggnad ovanpå Javascript) och Flow (en statisk typkontroll för Javascript). Faktum är att frontend redan har nått en lösning på problemet med det dåliga typ-systemet i Javascript.

Det finns ingen standardbibliotek i webbläsaren som sådan – det finns några inbyggda objekt och "magiska" funktioner i webbläsare. Men jag skulle säga att det standardbiblioteket i Javascript faktiskt saknas. Detta problem löstes för länge sedan av jQuery (alla använde jQuery med alla prototyper, hjälpare och funktioner som är nödvändiga för arbete). Nu använder alla Lodash:

Callback-häxan. Jag tror att alla har sett Javascript-kod för ungefär 5 år sedan och att den liknade en "nudel" av otroliga sammanflätningar av callbacks. Nu har detta problem lösts (med utgivningen av ES-15 eller ES-16), man har lagt till promises till Javascript och alla kan andas lite lättare för en tid.

Tills Promice-häxan kom... Jag vet inte hur frontend-industrin lyckas, men de kör hela tiden in sig i underliga avgrunder. De lyckades också skapa en "häxa" av promises. Sedan löste man detta problem genom att lägga till en ny primitiv – async/await:

Med asynkronitet är problemet löst. Async/await är en ganska populär konstruktion i olika språk. I Python och andra finns det en sådan metod – den fungerar riktigt bra. Problemet är löst.

Vilket problem är inte löst? Den exponentiellt ökande komplexiteten i ramverk, komplexiteten i ekosystemet och själva programmen.

• Syntaxen i Javascript är lite konstig. Vi vet alla om problemen med att addera en array och ett objekt och andra knepigheter.
• Javascript är multiparadigmt. Just nu är det en särskilt brådskande fråga, när ekosystemet är väldigt stort:
  • alla skriver i olika stilar – några skriver strukturellt, andra skriver funktionellt, olika utvecklare skriver på olika sätt;
  • från olika paket (packages) kommer olika paradigmer, när du använder olika paket;
  • det finns mycket "skoj" med funktionell programmering i Javascript – biblioteket ramda har dykt upp och nu kan ingen läsa program skrivna med det biblioteket.

• Det här bidrar till en stor påverkan på ekosystemet, och det har växt otroligt. Paketen är inkompatibla med varandra: vissa använder promises, andra async/await, andra callbacks. Dessutom skriver man i olika paradigmer!
• Det leder till att projekt är svåra att stödja. Det är svårt att hitta buggar om du inte kan läsa koden.

Vad är Web Assembly?

De modiga killarna från Mozilla Foundation och en rad andra företag har kommit på något som kallas Web Assembly. Vad är det?

• Det är en inbyggd virtuell maskin i webbläsaren som stödjer ett binärt format.
• Binära program körs nästan som inbyggda program, det vill säga webbläsaren behöver inte parsa all 'spagetti' Javascript-kod varje gång.
• Alla webbläsare har meddelat stöd.
• Eftersom detta är bytekod kan man skriva en kompilator för vilket språk som helst.
• De fyra största webbläsarna levereras redan med stöd för Web Assembly.
• Snart förväntar vi oss nativt stöd i Go. En sådan ny arkitektur har redan lagts till: GOARCH=wasm GOOS=js (snart). Just nu är den, såvitt jag förstår, inte funktionell, men det finns ett uttalande om att det definitivt kommer att finnas i Go.

Vad ska man göra nu? GopherJS

Eftersom vi ännu inte har stöd för Web Assembly finns det en transpiler, GopherJS.

• Koden i Go transpileras till "ren" 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å allt som helst).
• Det finns stöd för nästan allt som finns i Go, inklusive gorutiner och kanaler… – allt som vi älskar och känner till.
• Nästan hela standardbiblioteket stöds, förutom de paket som inte är meningsfulla att stödja i webbläsaren: syscall, nätverksinteraktioner (det finns en net/http-klient, men ingen server, och klienten emuleras via XMLHttpRequest). Överlag är hela standardbiblioteket tillgängligt – här är det i webbläsaren, här är stdlib Go, som vi älskar.
• Hela paketekosystemet i Go, alla tredjepartslösningar (templating och liknande) kan kompileras med GopherJS och köras i webbläsaren.

Att få GopherJS är mycket enkelt – det är ett vanligt Go-paket. Vi kör go get, och vi har GopherJS-kommandot för att bygga applikationen:

Så här ser ett litet hello world ut…

…En vanlig Go-program, ett vanligt paket fmt från standardbiblioteket och Binding Js för att nå webbläsarens API. Println kommer slutligen att omvandlas till en console log och webbläsaren kommer att skriva "Hello gophers"! Så enkelt är det: vi gör GopherJS build – kör i webbläsaren – allt fungerar!

Vad finns för närvarande? Bindningar

Det finns bindningar för alla populära js-ramverk:

• JQuery;
• Angular.js;
• D3.js för att skapa diagram och arbeta med stora datamängder;
• React.js;
• VueJS;
• det finns till och med stöd för Electron (så vi kan redan nu skriva skrivbordsapplikationer med "Electron");
• och det mest underhållande – är WebGL (vi kan skapa fullgrafiska applikationer, inklusive spel med 3D-grafik, musik och alla funktioner);
• och många fler bindningar till alla populära javascript-ramverk och bibliotek.

Ramverk

1. Det finns redan ett webbramverk som är speciellt utvecklat för GopherJS – Vecty. Detta är en fullständig analog av React.js, men utvecklad i Go, med GopherJS-specifikation.
2. Det finns spelframeworks (överraskande nog!). Jag har hittat två av de mest populära:
   • Engo;
   • Ebiten.

Jag ska visa ett par exempel på hur det ser ut och vad som redan kan skrivas i Go:

Eller det alternativet (jag hittade ingen 3D-shooter, men kanske finns det en):

Vad föreslår jag?

För närvarande befinner sig frontend-industrin i ett sådant tillstånd, att alla språk som tidigare klagade på Javascript nu kommer att strömma dit. Nu kommer alla att kompilera till "Web Assembly". Vad behöver vi för att få en värdig plats där som "gophers"?

I Go är det traditionellt sett en systemprogrammeringsspråk, och det finns praktiskt taget inga bibliotek för att arbeta med UI. Det finns något, men det är halvövergivet och halvfunktionsdugligt.

Och nu har vi ett bra tillfälle att skapa UI-bibliotek på Go som kan köras på GopherJS! Äntligen kan vi skriva vårt eget ramverk! Det är dags att skriva ett ramverk, och det kommer att vara ett av de första och få tidig anpassning, och du kommer att bli en stjärna (om det är ett bra ramverk).

Vi kan anpassa mängder av olika paket som redan finns i Go-ekosystemet för att passa webbläsarens specifikationer (till exempel en templating-motor). De kommer redan att fungera, men vi kan skapa bekväma omslag för att enkelt kunna rendera innehåll direkt i webbläsaren. Dessutom kan vi skapa en tjänst som kan rendera samma sak både på servern och klienten med samma kod – precis som frontend-utvecklare älskar (men nu på Go).

Vi kan skriva ett spel! Bara för skojs skull…

Det var allt från mig.

Frågor

Fråga (härefter – F): – Skriver jag i Go eller i Js?

AG: – Du skriver med Go-rutiner, kanaler, strukturer, inbäddning – allt… Du prenumererar på ett event och skickar dit en funktion.

L: – Så jag skriver i "ren" Js?

AG: – Nej, du skriver som om du använde Go och kopplar upp dig mot webbläsarens API (API:t har förblivit oförändrat). Du kan skriva dina egna omslag så att meddelanden kommer till kanalen – det är ju inte svårt.

L: – Vad sägs om mobil?

AG: – Jag har absolut sett: det finns bindningar för Cordova som Js kör. I React Native – jag vet inte; kanske finns det, kanske inte (jag har inte varit så intresserad). Spelmotorn N-go stödjer både mobilapplikationer – både iOS och Android.

L: – Fråga om Web Assembly. Det tar upp allt mer plats, trots komprimering och 'zipning'… Kommer vi att döda frontend-världen ännu mer på det här sättet?

AG: – Web Assembly är ett binärt format, och per standard kan det inte vara större än text i den slutliga releasen… Du dras till runtime, men det är samma sak som att dra in JavaScripts standardbibliotek när det inte finns, därför använder vi någon typ av Lodash. Jag vet inte hur mycket Lodash tar.

L: – Tydligt mindre än runtime…

AG: – I "rent" Javascript?

L: – Ja. Vi komprimerar det ju innan vi skickar…

AG: – Men det här är ju text… I allmänhet är en megabyte ganska mycket, men det är allt (du har hela runtime). Sedan skriver du din affärslogik som ökar din binärfil med 1 %. Jag ser inte att det dödar frontend. Dessutom kommer Web Assembly att fungera snabbare än Javascript av uppenbara skäl – det behöver inte tolkas.

L: – Det är fortfarande en diskussionspunkt… Det finns ännu ingen standardimplementering av "Vasm" (Web Assembly) som gör att man kan döma entydigt. Konceptuellt – ja: vi förstår alla att binärfilen bör vara snabbare, men den nuvarande implementeringen av V8 är väldigt effektiv.

AG: – Ja.

L: – Kompileringen fungerar verkligen mycket bra där och det är inte säkert att det kommer att ge stora fördelar.

AG: – Stora killar jobbar också med Web Assembly.

L: – Just nu verkar det som att det är svårt att döma om Web Assembly. Det har pratats i flera år, men verkliga framsteg som man kan ta på är få.

AG: – Möjligt. Vi får se.

L: – Vi har inga problem på backend… Kanske borde vi lämna dessa problem till frontend? Varför ge oss in där?

AG: – Vi måste ha en personal av frontendare.

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com