Takimi në Kiev Go Maj 2018:
Moderator: - Pershendetje te gjitheve! Faleminderit që jeni këtu! Sot kemi dy folës zyrtarë - Lyosha dhe Vanya. Do të ketë edhe dy të tjera nëse kemi kohë. Folësi i parë është Alexey Grachev, ai do të na tregojë për GopherJS.
Alexey Grachev (në tekstin e mëtejmë - AG): – Unë jam një zhvillues i Go dhe shkruaj shërbime në internet në Go. Ndonjëherë duhet të merreni me pjesën e përparme, ndonjëherë duhet të ngjiteni atje me doreza. Unë dua të flas për përvojën time dhe kërkimin mbi Go on the frontend.
Legjenda është kjo: së pari do të flasim përse duam ta ekzekutojmë Go në front, pastaj do të flasim se si mund ta bëjmë atë. Ka dy mënyra - Web Asambleja dhe GopherJS. Le të shohim se në çfarë gjendje janë këto vendime dhe çfarë mund të bëhet.
Çfarë nuk shkon me frontend?
Të gjithë pajtohen se gjithçka është në rregull me frontin?
Pak teste? Ndërtim i ngadalshëm? Ekosistemi? Mirë.
Në lidhje me front-endin, më pëlqen një citim që një nga zhvilluesit e frontit tha në librin e tij:
Javascript nuk ka një sistem tipi. Tani do të përmend problemet që kam hasur gjatë punës sime dhe do të shpjegoj se si zgjidhen ato.
Sistemi i tipit në përgjithësi është i vështirë për t'u quajtur një sistem tipi në Javascript - ka rreshta që tregojnë llojin e një objekti, por në fakt kjo nuk ka të bëjë fare me llojet. Ky problem është zgjidhur në TypeScript (një shtesë për Javascript) dhe Flow (një kontrollues statik i llojeve në Javascript). Në fakt, frontend tashmë ka arritur deri në zgjidhjen e problemit të një sistemi të tipit të keq në Javascript.
Nuk ka asnjë bibliotekë standarde në shfletues si e tillë - ka disa objekte të integruara dhe funksione "magjike" në shfletues. Por unë nuk kam një bibliotekë standarde në Javascript si të tillë. Ky problem tashmë është zgjidhur nga jQuery (të gjithë përdorën jQuery me të gjitha prototipet, ndihmësit, funksionet që duheshin për të punuar). Tani të gjithë përdorin Lodash:
kthim thirrje ferr. Unë mendoj se të gjithë e panë kodin Javascript rreth 5 vjet më parë, dhe dukej si një "petë" nga një ndërlikim i jashtëzakonshëm i thirrjeve. Tani ky problem është zgjidhur (me lëshimin e ES-15 ose ES-16), premtimet u shtuan në Javascript dhe të gjithë filluan të marrin frymë më lehtë për një kohë.
Derisa erdhi ferri i Promise... Nuk e di se si ia del mbanë industria e nivelit të parë, por ata gjithmonë e çojnë veten në ndonjë xhungël të çuditshme. Ne gjithashtu arritëm të bënim ferr në "premtime". Pastaj e zgjidhëm këtë problem duke shtuar një primitiv të ri - async / prit:
Me asinkroni, problemi zgjidhet. Async/wait është një primitiv mjaft i njohur në gjuhë të ndryshme. Python dhe të tjerët e kanë këtë qasje - është mjaft e mirë. Problemi u zgjidh.
Cili problem nuk zgjidhet? Kompleksiteti në rritje eksponenciale i kornizave, kompleksiteti i ekosistemit dhe vetë programeve.
- Sintaksa e Javascript është pak e çuditshme. Të gjithë i dimë problemet me shtimin e një grupi dhe një objekti dhe truke të tjera.
- Javascript është multi-paradigmë. Tani ky është një sistem veçanërisht i ngutshëm kur ekosistemi është shumë i madh:
- të gjithë shkruajnë në stile të ndryshme - dikush shkruan në mënyrë strukturore, dikush shkruan në mënyrë funksionale, zhvillues të ndryshëm shkruajnë ndryshe;
- nga paketa (pako) të ndryshme paradigma të ndryshme kur përdorni paketa të ndryshme;
- shumë "argëtim" me programimin funksional në Javascript - u shfaq biblioteka rambda dhe tani askush nuk mund të lexojë programet e shkruara në këtë bibliotekë.
- E gjithë kjo ka një ndikim të madh në ekosistem, dhe ai është rritur në mënyrë të jashtëzakonshme. Paketat janë të papajtueshme me njëra-tjetrën: disa janë në premtime, disa janë në async/pritje, disa janë në kthim. Ata gjithashtu shkruajnë në paradigma të ndryshme!
- Kjo e bën të vështirë mirëmbajtjen e projektit. Është e vështirë të gjesh një gabim nëse nuk mund ta lexosh kodin.
Çfarë është Web Asambleja?
Djemtë e guximshëm nga Fondacioni Mozilla dhe një numër kompanish të tjera dolën me një gjë të tillë si Web Assembly. Çfarë është kjo?
- Kjo është një makinë virtuale e integruar në shfletues që mbështet formatin binar.
- Programet binare arrijnë atje, ato ekzekutohen pothuajse në mënyrë origjinale, domethënë, shfletuesi nuk ka nevojë të analizojë të gjitha "petët" e kodit javascript çdo herë.
- Të gjithë shfletuesit kanë deklaruar mbështetje.
- Meqenëse ky është bytecode, mund të shkruani një përpilues për çdo gjuhë.
- Katër shfletuesit kryesorë tashmë dërgohen me mbështetjen e Web Asamblesë.
- Ne presim mbështetje vendase në Go së shpejti. Kjo arkitekturë e re tashmë është shtuar: GOARCH=wasm GOOS=js (së shpejti). Deri tani, me sa kuptoj unë, nuk është funksional, por ka një deklaratë që do të jetë patjetër në Go.
Çfarë duhet të bëni tani? GopherJS
Ndërsa ne nuk kemi mbështetje Web Asambleja, ekziston një transpilues si GopherJS.
- Kodi Go është transpiluar në Javascript "të pastër".
- Ekzekutohet në të gjithë shfletuesit - nuk ka veçori të reja që mbështeten vetëm nga shfletuesit modernë (ky është Vanilla JS, i cili funksionon në çdo gjë).
- Ka mbështetje për pothuajse gjithçka që është në Go, duke përfshirë gorutinat dhe kanalet ... - gjithçka që duam dhe dimë kaq shumë.
- Pothuajse e gjithë biblioteka standarde mbështetet, me përjashtim të atyre paketave që nuk ka kuptim të mbështeten në shfletues: syscall, ndërveprime net (ka një klient net / http, por jo server, dhe klienti emulohet përmes XMLHttpRequest) . Në përgjithësi, e gjithë biblioteka standarde është e disponueshme - këtu është në shfletues, këtu është Go stdlib që ne duam.
- I gjithë ekosistemi i paketës në Go, të gjitha zgjidhjet e palëve të treta (shabllonet, etj.) mund të kompilohen me GopherJS dhe të ekzekutohen në shfletues.
Marrja e GopherJS është shumë e lehtë - është thjesht një paketë e zakonshme Go. Ne bëjmë një "go get" dhe kemi një komandë GopherJS për të ndërtuar aplikacionin:
Këtu është një botë kaq e vogël përshëndetje ...
...Një program i rregullt Go, një paketë e rregullt fmt e bibliotekës standarde dhe Binding Js për të arritur në API të shfletuesit. Println përfundimisht do të konvertohet në regjistrin e konsolës dhe shfletuesi do të shkruajë "Përshëndetje gophers"! Është kaq e thjeshtë: ne bëjmë ndërtimin e GopherJS - e lëshojmë atë në shfletues - gjithçka funksionon!
Çfarë ka për momentin? Lidhjet
Ekzistojnë lidhje për të gjitha kornizat e njohura js:
- jquery;
- Këndore.js
- D3.js për hartimin dhe punën me të dhëna të mëdha;
- Reagoni.js
- VueJS;
- madje ka mbështetje për Electron (d.m.th., ne tashmë mund të shkruajmë aplikacione desktop në Electron);
- dhe gjëja më qesharake është WebGL (mund të bëjmë aplikacione me grafikë të plotë, duke përfshirë lojëra me grafikë 3D, muzikë dhe të gjitha të mirat);
- dhe shumë lidhje të tjera për të gjitha kornizat dhe bibliotekat e njohura të javascript.
Strukturë
- Ekziston një kornizë ueb e zhvilluar tashmë posaçërisht për GopherJS - Vecty. Ky është një analog i plotë i React.js, por i zhvilluar vetëm në Go, me specifikat e GopherJS.
- Ka çanta lojërash (papritmas!). Kam gjetur dy nga më të njohurit:
- engo;
- Ebiten.
Unë do të demonstroj disa shembuj se si duket dhe çfarë mund të shkruhet tashmë në Go:
Ose ky opsion (nuk gjeta një revole 3D, por mbase ekziston):
Çfarë sugjeroj?
Tani industria e përparme është në një gjendje të tillë që të gjitha gjuhët që më parë qanin nga Javascript do të nxitojnë atje. Tani gjithçka do të përpilohet në "Web Assemblies". Çfarë na duhet për të zënë një vend të denjë atje si “gophers”?
Në Go, tradicionalisht ka shkuar se është një gjuhë programimi e Sistemit dhe praktikisht nuk ka biblioteka për të punuar me UI. Ka diçka, por është gjysmë e braktisur, gjysmë jofunksionale.
Dhe tani - një shans i mirë për të krijuar biblioteka UI në Go që do të funksionojnë në GopherJS! Më në fund mund të shkruani kornizën tuaj! Ka ardhur koha kur mund të shkruani një kornizë, dhe do të jetë një nga të parat dhe do të miratohet herët, dhe do të jeni një yll (nëse është një kornizë e mirë).
Ju mund të përshtatni shumë paketa të ndryshme që ekzistojnë tashmë në ekosistemin Go me specifikat e shfletuesit (për shembull, motori Template). Ata tashmë do të funksionojnë, ju mund të bëni lidhje të përshtatshme në mënyrë që të mund të jepni lehtësisht përmbajtjen direkt në shfletues. Plus, mund të krijoni, për shembull, një shërbim që mund të japë të njëjtën gjë në server dhe në pjesën e përparme, duke përdorur të njëjtin kod - gjithçka që pëlqejnë zhvilluesit e frontit (vetëm tani në Go).
Ju mund të shkruani një lojë! Thjesht për argëtim…
Kjo është gjithçka që doja të thoja.
Pyetjet tuaja
Pyetja (më tej referuar si P): – Po shkruaj në Go apo Js?
AG: – Ju shkruani rutina, kanale, struktura, embedding – gjithçka në Go… Ju abonoheni në një ngjarje, kaloni një funksion atje.
NË: - Domethënë unë shkruaj mbi J-të "lakuriq"?
AG: - Jo, ju shkruani sikur në Go dhe lidheni me API të shfletuesit (API nuk ka ndryshuar). Ju mund të shkruani lidhjet tuaja në mënyrë që mesazhet të vijnë në kanal - nuk është e vështirë.
NË: - Po celulari?
AG: - E pashë me siguri: ka lidhës për copën Cordova që lëshon Js. Në React Native, nuk e di; ndoshta ka, ndoshta jo (jo veçanërisht i interesuar). Motori i lojërave N-go mbështet të dy aplikacionet celulare - si iOS ashtu edhe Android.
NË: – Një pyetje rreth Web Asamblesë. Gjithnjë e më shumë vende po zënë, pavarësisht koncizitetit, “zipping”... A nuk do ta vrasim edhe më shumë botën e frontit në këtë mënyrë?
AG: - Asambleja e uebit është një format binar dhe binar i parazgjedhur nuk mund të jetë më i madh se teksti në versionin përfundimtar ... Ju tërhiqeni nga koha e ekzekutimit, por kjo është e njëjtë me tërheqjen në bibliotekën standarde Javascript kur ajo nuk është aty, kështu që ne përdorni disa Lodash. Nuk e di sa kohë i duhet Lodashit.
NË: - Natyrisht më pak se koha e ekzekutimit ...
AG: - Në Javascript "të pastër"?
NË: - Po. Ne e ngjeshim atë përpara se ta dërgojmë ...
AG: - Por ky është tekst ... Në përgjithësi, një megabajt është si shumë, por kjo është e gjitha (ju keni të gjithë kohën e ekzekutimit). Më pas, ju shkruani logjikën tuaj të biznesit që do të rrisë binarin tuaj me 1%. Deri më tani nuk e shoh që të vrasë frontin. Për më tepër, Web Asambleja do të funksionojë më shpejt se Javascript për arsyen e qartë - nuk ka nevojë të analizohet.
NË: - Deri më tani, një pikë e diskutueshme ... Nuk ka ende një zbatim referues të "Wasma" (Web Asamble), në mënyrë që të mund të gjykohet pa mëdyshje. Konceptualisht, po: të gjithë e kuptojmë se binarja duhet të jetë më e shpejtë, por zbatimi aktual i të njëjtit V8 është shumë efikas.
AG: - Po.
NË: - Përpilimi atje funksionon vërtet shumë mirë dhe nuk është fakt që do të ketë një avantazh të madh.
AG: - Web Asambleja është bërë edhe nga djem të mëdhenj.
NË: - Deri tani, më duket, është ende e vështirë të gjykosh Web Assembly. Për shumë vite ka pasur bisedime, por ka pak arritje reale që mund të ndihen.
AG: - Ndoshta. Le të shohim.
NË: – Nuk kemi probleme në pjesën e përparme… Ndoshta duhet t’i lëmë këto probleme në pjesën e përparme? Pse të shkosh atje?
AG: - Duhet të mbajmë stafin e fronteve.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com