Kyiv Go Meetup 2018. május:
Házigazda: – Mindenki, üdvözlöm! Köszönöm, hogy itt vagytok! Ma két hivatalos előadónk van – Alex és Vanya. Lesz még két másik, ha lesz időnk. Az első előadó – Alexey Grachev, ő fog beszélni a GopherJS-ről.
Alexey Grachev (a továbbiakban – AG): – Én Go-fejlesztő vagyok, webszolgáltatásokat írok Go nyelven. Néha bele kell nyúlnom a frontendbe, néha kézzel kell dolgoznom. Szeretném megosztani veletek a tapasztalataimat és a Go frontendben való használatának kutatásait.
A legenda úgy szól: először beszélünk arról, miért szeretnénk Go-t futtatni a frontendben, majd arról, hogyan tehetjük ezt. Két út van – Web Assembly és GopherJS. Megnézzük, milyen állapotban vannak ezek a megoldások és mit lehet velük kezdeni.
Mi a probléma a frontenddel?
Mindenki egyetértene abban, hogy minden rendben van a frontenddel?
Kevés teszt? Lassú build? Ökoszisztéma? Rendben.
A frontendre vonatkozóan tetszik egy idézet, amit az egyik frontend fejlesztő mondott a könyvében:
A Javascriptben nincs típuskezelő rendszer. Most problémákat fogok említeni, amelyekkel a munkám során találkoztam, és elmagyarázom, hogyan oldják meg ezeket.
A Javascript típuskezelő rendszert aligha nevezhetjük rendszernek – léteznek stringek, amelyek az objektumok típusát jelölik, de valójában semmi közük a típusokhoz. Ezt a problémát a TypeScript (a Javascript kiterjesztése) és a Flow (a Javascript típusok statikus ellenőrzője) oldotta meg. A frontend már eljutott a Javascript gyenge típuskezelő rendszerének a problémájának a megoldásáig.
A böngészőben gyakorlatilag nincs standard könyvtár – vannak beépített objektumok és "varázslatos" funkciók a böngészőkben. De a Javascriptben alapvetően nincs standard könyvtár. Ezt a problémát egykor a jQuery oldotta meg (mindenki használta a jQuery-t minden prototípussal, segítőkkel és a működéshez szükséges funkciókkal). Ma már mindenki a Lodash-ot használja:
Callback hell. Gondolom, mindannyian láttunk Javascript kódot körülbelül 5 évvel ezelőtt, és az „tésztaszerű” volt, tele hihetetlen összekuszált callback-ekkel. Ma már ezt a problémát megoldották (az ES-15 vagy ES-16 megjelenésével), bevezették a Javascriptbe a promise-okat, és mindenki kicsit könnyebben lélegzett egy ideig.
Amíg meg nem érkezett a Promise hell... Nem tudom, hogyan sikerül a frontend iparnak, de mindig valamilyen furcsaságba keverik magukat. A promise-okból is megoldották a hell-t. Aztán megoldották ezt a problémát az új primitív bevezetésével – async/await:
Az aszinkronitás probléma megoldva. Az async/await elég népszerű primitív különböző nyelvekben. A Pythonban és másokban is van egy ilyen megközelítés — elég jó. A probléma megoldva.
Melyik probléma maradt megoldatlan? A keretrendszerek exponenciálisan növekvő bonyolultsága, az ökoszisztéma bonyolultsága és maguk a programok.
- A Javascript szintaxisa kicsit furcsa. Mindannyian ismerjük a tömbök és objektumok összeadásával kapcsolatos problémákat és más trükköket.
- A Javascript többparadigmás. Ez különösen aktuális rendszer, amikor az ökoszisztéma nagyon nagy:
- mindenki különböző stílusokban ír — valaki strukturálisan, valaki funkcionálisan, különböző fejlesztők másképp írnak;
- különböző csomagok (packages) különböző paradigmákat használnak, amikor különböző csomagokat használsz;
- nagyon sok „szórakozás” van a funkcionális programozással a Javascriptban — megjelent a rambda könyvtár, és most senki sem tudja elolvasni az ebben a könyvtárban írt programokat.
- Mindez nagy hatással van az ökoszisztémára, és hihetetlenül megnőtt. A csomagok nem kompatibilisek egymással: valaki ígéreteken alapul, valaki async/await-t, valaki callback-eket használ. Ráadásul különböző paradigmákban írnak!
- Ez oda vezet, hogy a projektet nehéz karbantartani. Nehéz hibákat találni, ha nem tudod elolvasni a kódot.
Mi az a Web Assembly?
A bátor fiúk a Mozilla Alapítványtól és más cégektől kitalálták azt, amit Web Assembly-nek hívunk. Mi ez?
- Ez egy böngészőkbe beépített virtuális gép, ami támogatja a bináris formátumot.
- A bináris programok odakerülnek, gyakorlatilag natívan futnak, ami azt jelenti, hogy a böngészőnek nem kell minden alkalommal az összes Javascript kódot "parse"-olni.
- Minden böngésző bejelentette a támogatást.
- Mivel ez byte-kód, bármely nyelvhez írhatsz fordítót.
- A négy legfontosabb böngésző már támogatja a Web Assembly-t.
- Hamarosan natív támogatást várunk a Go-ban. Ez az új architektúra már hozzá lett adva: GOARCH=wasm GOOS=js (hamarosan). Jelenleg, amennyire tudom, nem funkcionális, de van kijelentés arról, hogy ez biztosan lesz a Go-ban.
Mit tegyünk most? GopherJS
Míg nincs Web Assembly támogatásunk, van egy transzpiler, mint a GopherJS.
- A Go kód transzpileződik "tiszta" Javascript-ra.
- Minden böngészőben fut — nincs új funkció, amit csak a modern böngészők támogatnak (ez Vanilla JS, ami bármin működik).
- A Go szinte minden, beleértve a goroutine-okat és a csatornákat is, támogatott… – mindaz, amit olyan nagyon szeretünk és ismerünk.
- Majdnem az összes standard könyvtár támogatott, kivéve azokat a csomagokat, amelyeknek nincs értelme a böngészőben támogatni: syscall, a hálózati interakciók (van net/http kliens, de nincs szerver, a kliens pedig XMLHttpRequest-en keresztül van emulálva). Összességében az összes standard könyvtár elérhető – itt van a böngészőben, itt van a Go stdlib, amit szeretünk.
- A Go csomag teljes ökoszisztémája, minden harmadik féltől származó megoldás (sablonozás stb.) GopherJS segítségével lefordítható és a böngészőben futtatható.
A GopherJS beszerzése nagyon egyszerű – ez egy szokásos Go csomag. Csináljuk a go get parancsot, és van egy GopherJS parancsunk az alkalmazás építéséhez:
Itt van egy ilyen kis hello world...
…Egy szokásos Go program, a szokásos fmt csomag a standard könyvtárból és a Js Binding, hogy elérjük a böngésző API-ját. A Println végül console log-ra lesz átkonvertálva, és a böngésző kiírja, hogy “Hello gophers”! Így egyszerű: csinálunk egy GopherJS build-et – elindítjuk a böngészőben – minden működik!
Jelenleg mi áll rendelkezésre? Bindings
Minden népszerű js-keretrendszerhez van binding:
- JQuery;
- Angular.js;
- D3.js grafikonok készítéséhez és nagy adatokkal való munkához;
- React.js;
- VueJS;
- még az Electron támogatása is van (tehát már most is írhatsz desktop alkalmazásokat ‘Electron’-ra);
- és a legszórakoztatóbb a WebGL (teljesen grafikával ellátott alkalmazásokat, beleértve a 3D-s játékokat, zenét és minden egyebet is készíthetünk);
- és sok más binding a népszerű javascript-keretrendszerekhez és könyvtárakhoz.
Framework
- Már létezik egy GopherJS-re kifejezetten kifejlesztett web-keretrendszer – Vecty. Ez a teljes értékű React.js analógja, csak Go nyelven, a GopherJS sajátosságaival.
- Van játékcsomag (meglepően!). Két legnépszerűbbet találtam:
- Engo;
- Ebiten.
Bemutatok néhány példát, hogyan néz ki ez, és mit lehet már most írni Go-ban:
Vagy egy ilyen verzió (3D-s lövöldözős játékot nem találtam, de talán létezik):
Mit ajánlok?
Jelenleg a frontend iparág ilyen helyzetben van, hogy minden olyan nyelv, amely eddig sírt a Javascript miatt, most be fog ugrani. Mostantól mindenki a ‘Web Assembly’-be fog fordulni. Mire van szükségünk, hogy méltó helyet szerezzünk ott ‘goferekként’?
A Go nyelvről hagyományosan úgy tartják, hogy ez egy rendszerszintű programozási nyelv, és gyakorlatilag nincsenek könyvtárak a UI-hoz való munkára. Van valami, de félig elhagyott és félig nem funkcionális.
És most itt a jó alkalom, hogy UI könyvtárakat készítsünk Go-ban, amelyek a GopherJS-en futnak! Végre elkészítheted a saját keretrendszeredet! Elérkezett az idő, hogy megírd a keretet, és az egyik legelső lesz, így korai adaptációt kap, és te leszel a sztár (ha jó keretrendszer lesz).
Számos különböző csomagot lehet adaptálni, amelyek már léteznek a Go ökoszisztémában, a böngésző sajátosságainak megfelelően (például sablonszerkesztő). Ezek már működnek, el lehet készíteni kényelmes csomagolásokat, hogy könnyen lehessen tartalmat renderelni közvetlenül a böngészőben. Továbbá létrehozhatsz például egy szolgáltatást, amely képes ugyanazt renderelni a szerveren és a frontend-en, ugyanazzal a kóddal – mindez úgy, ahogy a frontend fejlesztők szeretik (csak most Go-ban).
Írhatsz egy játékot! Csak szórakozásból…
Nálam ennyi.
Kérdések
Kérdés (a továbbiakban – K): – Go-n írok vagy Js-en?
AG: – Go rutint, csatornákat, struktúrákat, embeddinget írsz – mindent… Közvetítesz egy eseményre, átadsz egy függvényt.
K: – Tehát én „tiszta” Js-en írok?
AG: – Nem, mintha Go-n írnál, és csatlakozol a böngésző API-jához (az API egyébként nem változott). Írhatsz saját csomagokat, hogy üzenetek érkezzenek a csatornára – ez nem nehéz.
K: – Mi a helyzet a mobiltelefonokkal?
AG: – Pontosan láttam: vannak kötések a Cordova patch-hez, amelyeket a Js indít. A React Native-ról nem tudom; lehet, hogy van, lehet, hogy nincs (nem igazán érdekeltem). Az N-go játékmotor támogatja a mobilalkalmazásokat – mind az iOs-t, mind az Androidot.
K: – Kérdés a Web Assembly-ről. Egyre több helyet foglal el, a tömörítés ellenére, „zip-elt”… Nem öljük meg ezzel még jobban a frontend világát?
AG: – A Web Assembly egy bináris formátum, és a bináris alapértelmezés szerint nem lehet nagyobb, mint a szöveg a végső kiadásban… A futási időt szeretnéd magaddal hozni, de ez ugyanolyan, mint a Javascript szabványos könyvtárának magaddal hozása, amikor az nincs, ezért használunk valamilyen Lodash-t. Nem tudom, hogy a Lodash mennyi helyet foglal.
K: – Nyilvánvalóan kevesebb, mint a futási idő…
AG: – A „tiszta” Javascript-en?
K: – Igen. Már tömörítjük, mielőtt elküldjük…
AG: – De ez egy szöveg… Szóval, egy megabájt – ez nagyjából sok, de ez – az egész (neked van minden futási időd). Aztán írod a saját üzleti logikádat, amely 1%-kal növeli a binárist. Egyelőre nem látom, hogy ez megölné a frontendot. Főleg, hogy a Web Assembly gyorsabban fog működni, mint a Javascript, nyilvánvaló okból – nem kell elemezni.
K: – Még vita alatt áll… Még nincs egy olyan etalon megvalósítás a "Vasmával" (Web Assembly), amiből egyértelműen lehetne ítélni. Konceptuálisan – igen: mindannyian értjük, hogy a binárisnak gyorsabbnak kell lennie, de a jelenlegi V8 megvalósítás nagyon hatékony.
AG: – Igen.
K: – A fordítás ott valóban nagyon jól működik, és nem biztos, hogy nagy előnye lesz.
AG: – A Web Assembly-t is komoly cégek készítik.
K: – Egyelőre, úgy érzem, még nehéz megítélni a Web Assembly-t. Már hány éve beszélgetünk róla, de valós, kézzelfogható eredményekből viszont kevés van.
AG: – Lehetséges. Majd meglátjuk.
K: – Nincs problémánk a backenddel… Talán ezeket a problémákat a frontendben kellene hagyni? Miért kellene odamenni?
AG: – Kényszerűen tartani kell egy frontend csapatot.
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
