Kyiv Go Meetup 2018. május:
moderátor: - Sziasztok! Köszönöm, hogy itt vagy! Ma két hivatalos előadónk van - Lyosha és Vanya. Lesz még kettő, ha lesz időnk. Az első előadó Alexey Grachev, ő mesél nekünk a GopherJS-ről.
Alexey Grachev (a továbbiakban - AG): – Go-fejlesztő vagyok, és webszolgáltatásokat írok a Go-ban. Néha a frontenddel kell foglalkozni, néha oda kell mászni kilincsekkel. Szeretnék beszélni a Go on the frontenddel kapcsolatos tapasztalataimról és kutatásaimról.
A legenda a következő: először arról beszélünk, hogy miért akarjuk futtatni a Go-t a frontenden, majd arról, hogyan tudjuk ezt megtenni. Két módja van: Web Assembly és GopherJS. Lássuk, milyen állapotban vannak ezek a döntések, és mit lehet tenni.
Mi a baj a frontenddel?
Mindenki egyetért abban, hogy minden rendben van a frontenddel?
Kevés teszt? Lassú építkezés? Ökoszisztéma? Bírság.
Ami a front-endet illeti, tetszik egy idézet, amit az egyik front-end fejlesztő mondott a könyvében:
A Javascriptnek nincs típusrendszere. Most megnevezem azokat a problémákat, amelyekkel a munkám során találkoztam, és elmagyarázom, hogyan oldják meg őket.
A típusrendszert általában nehéz Javascriptben típusrendszernek hívni – vannak sorok, amelyek az objektum típusát jelzik, de ennek valójában semmi köze a típusokhoz. Ezt a problémát a TypeScript (Javascript bővítmény) és a Flow (Javascript statikus típusellenőrzője) oldja meg. Valójában a frontend már eljutott odáig, hogy megoldja a rossz típusú rendszer problémáját Javascriptben.
A böngészőben mint olyanban nincs szabványos könyvtár – vannak beépített objektumok és „varázslatos” funkciók a böngészőkben. De nincs szabványos Javascript-könyvtáram, mint olyan. Ezt a problémát a jQuery már megoldotta (mindenki a jQuery-t használta az összes prototípussal, segédprogrammal, funkcióval, aminek működnie kellett). Most mindenki a Lodash-t használja:
visszahívás pokol. Azt hiszem, körülbelül 5 évvel ezelőtt mindenki látott Javascript kódot, és úgy nézett ki, mint egy „tészta” a visszahívások hihetetlen bonyolultságából. Most ez a probléma megoldódott (az ES-15 vagy ES-16 kiadásával), ígéreteket adtak a Javascripthez, és egy ideig mindenki könnyebben lélegzett.
Amíg el nem jött a Promice pokol... Nem tudom, hogy a front-end iparág hogyan boldogul, de mindig valami furcsa dzsungelbe hajtják magukat. Sikerült is pokolba hoznunk az „ígéreteket”. Aztán megoldottuk ezt a problémát egy új primitív hozzáadásával - async / await:
Az aszinkronizálással a probléma megoldódott. Az Async/await meglehetősen népszerű primitív a különböző nyelveken. A Python és mások is alkalmazzák ezt a megközelítést – ez elég jó. Probléma megoldódott.
Milyen probléma nincs megoldva? A keretrendszerek exponenciálisan növekvő összetettsége, az ökoszisztéma és maguk a programok összetettsége.
- A Javascript szintaxisa kicsit furcsa. Mindannyian ismerjük a tömb és egy objektum hozzáadásával és egyéb trükkökkel kapcsolatos problémákat.
- A Javascript több paradigma. Ez most különösen sürgető rendszer, amikor az ökoszisztéma nagyon nagy:
- mindenki más-más stílusban ír – valaki szerkezetileg, valaki funkcionálisan ír, a különböző fejlesztők másképp írnak;
- különböző csomagokból (csomagokból) különböző paradigmák, amikor különböző csomagokat használ;
- sok "móka" a funkcionális programozással Javascriptben - megjelent a rambda könyvtár, és most már senki sem tudja elolvasni az ebbe a könyvtárba írt programokat.
- Mindez nagy hatással van az ökoszisztémára, és hihetetlenül megnőtt. A csomagok nem kompatibilisek egymással: van, amelyik ígéret, van, amelyik async/wait, van, amelyik visszahíváson van. Különböző paradigmákban is írnak!
- Ez megnehezíti a projekt fenntartását. Nehéz hibát találni, ha nem tudja elolvasni a kódot.
Mi az a Web Assembly?
A Mozilla Alapítvány és számos más cég bátor srácai kitaláltak egy olyan dolgot, mint a Web Assembly. Mi ez?
- Ez egy böngészőbe épített virtuális gép, amely támogatja a bináris formátumot.
- A bináris programok eljutnak oda, szinte natív módon futnak le, vagyis a böngészőnek nem kell minden alkalommal elemeznie a javascript kód összes "tésztáját".
- Minden böngésző bejelentette a támogatást.
- Mivel ez bájtkód, bármilyen nyelvhez írhat fordítóprogramot.
- A négy fő böngésző már rendelkezik Web Assembly támogatással.
- Hamarosan natív támogatásra számítunk a Go-ban. Ez az új architektúra már hozzáadásra került: GOARCH=wasm GOOS=js (hamarosan). Egyelőre, ha jól értem, nem működőképes, de van egy nyilatkozat, hogy Go-ban biztosan lesz.
Mi a teendő most? GopherJS
Bár nem támogatjuk a Web Assembly-t, létezik olyan transzpiler, mint a GopherJS.
- A Go kód „tiszta” Javascript-be kerül átültetésre.
- Minden böngészőben fut - nincsenek olyan új funkciók, amelyeket csak a modern böngészők támogatnak (ez a Vanilla JS, amely bármin fut).
- Szinte minden támogatást kap, ami a Go-ban van, beleértve a gorutinokat és a csatornákat... - mindent, amit annyira szeretünk és ismerünk.
- Szinte a teljes szabványos könyvtár támogatott, kivéve azokat a csomagokat, amelyeket nincs értelme támogatni a böngészőben: syscall, net interakciók (van net / http kliens, de nincs szerver, és a kliens emulációja XMLHttpRequest-en keresztül történik) . Általában a teljes szabványos könyvtár elérhető - itt van a böngészőben, itt van a Go stdlib, amelyet szeretünk.
- A Go teljes csomag-ökoszisztémája, az összes harmadik féltől származó megoldás (sablonok stb.) a GopherJS segítségével lefordítható és a böngészőben futtatható.
A GopherJS beszerzése nagyon egyszerű – ez csak egy szokásos Go csomag. Megpróbáljuk felépíteni az alkalmazást, és van egy GopherJS parancsunk:
Íme egy ilyen kis helló világ...
...Egy szokásos Go program, a szabványos könyvtár szokásos fmt csomagja és Binding Js a böngésző API eléréséhez. A Println végül konzolnaplóvá lesz konvertálva, és a böngésző azt írja ki, hogy "Hello gophers"! Annyira egyszerű: elkészítjük a GopherJS-t – elindítjuk a böngészőben – minden működik!
Mi van jelen pillanatban? Kötések
Az összes népszerű js keretrendszerhez vannak kötések:
- jquery;
- Angular.js
- D3.js nagy adatok ábrázolásához és kezeléséhez;
- React.js
- VueJS;
- még az Electron támogatása is van (vagyis az Electronon már tudunk asztali alkalmazásokat írni);
- és a legviccesebb a WebGL (készíthetünk teljes grafikus alkalmazásokat, beleértve a 3D-s grafikát, zenét és minden jót);
- és sok más kötés minden népszerű JavaScript-keretrendszerhez és könyvtárhoz.
Keretrendszer
- Van egy webes keretrendszer, amelyet már kifejezetten a GopherJS-hez fejlesztettek ki – Vecty. Ez a React.js teljes értékű analógja, de csak a Go-ban fejlesztették ki, a GopherJS sajátosságaival.
- Játéktáskák vannak (hirtelen!). Találtam kettőt a legnépszerűbbek közül:
- engo;
- Ebiten.
Bemutatok néhány példát, hogyan néz ki, és mit lehet már írni a Go-ban:
Vagy ez a lehetőség (nem találtam 3D shootert, de lehet, hogy létezik):
mit javaslok?
Most a front-end ipar olyan állapotban van, hogy az összes nyelv, amely korábban kiáltott a Javascriptből, oda fog rohanni. Most minden a "Web Assemblies"-re fog fordítani. Mire van szükségünk, hogy ott méltó helyet foglaljunk el "gopherként"?
A Go-ban hagyományosan úgy ment, hogy ez egy System programozási nyelv, és gyakorlatilag nincs könyvtár a felhasználói felülettel való együttműködéshez. Van valami, de félig elhagyatott, félig nem működőképes.
És most – egy jó lehetőség, hogy olyan felhasználói felület-könyvtárakat készíts a Go-ban, amelyek GopherJS-en futnak majd! Végre megírhatod a saját keretedet! Eljött az idő, amikor írhatsz egy keretrendszert, és az elsők között lesz, korán elfogadják, és sztár leszel (ha jó keret).
A Go ökoszisztémában már meglévő számos különböző csomagot adaptálhat a böngésző sajátosságaihoz (például a Template motorhoz). Ezek már működni fognak, kényelmes kötéseket készíthet, hogy könnyedén, közvetlenül a böngészőben jelenítse meg a tartalmat. Ezenkívül készíthet például egy olyan szolgáltatást, amely ugyanazt a dolgot képes megjeleníteni a szerveren és a front-enden, ugyanazzal a kóddal – mindent, amit a front-end fejlesztők szeretnek (csak most Go-n).
Tudsz játékot írni! A hecc kedvéért…
Csak ennyit akartam mondani.
kérdések
Kérdés (a továbbiakban: Q): – Go vagy Js nyelven írok?
AG: – Rutinokat, csatornákat, struktúrákat, beágyazást ír – mindent a Go-ban… Feliratkozik egy eseményre, ott átad egy funkciót.
BAN BEN: - Vagyis a "meztelen" Js-re írok?
AG: - Nem, úgy írsz, mintha a Go-ban lennél, és csatlakozol a böngésző API-hoz (az API nem változott). Saját kötéseket írhat, hogy az üzenetek a csatornára érkezzenek - ez nem nehéz.
BAN BEN: - Mi a helyzet a mobillal?
AG: - Biztosan láttam: vannak kötőanyagok a Cordova patch-hez, amit Js elindít. A React Native-ben nem tudom; talán van, talán nem (nem különösebben érdekel). Az N-go játékmotor mindkét mobilalkalmazást támogatja – iO-t és Androidot egyaránt.
BAN BEN: – Kérdés a Web Assembly-ről. Egyre több helyet foglalnak el, a tömörség, „cipzározás” ellenére is... Nem öljük még jobban így a frontend világát?
AG: - A Web Assembly egy bináris formátum, és az alapértelmezett bináris nem lehet nagyobb, mint a végső kiadás szövege... A futtatókörnyezet húzza, de ez ugyanaz, mint a Javascript szabványkönyvtár behúzása, amikor az nincs, ezért mi használj valami Lodash-t. Nem tudom, mennyi ideig tart Lodash.
BAN BEN: - Nyilvánvalóan kevesebb, mint a futásidő...
AG: - "Tiszta" Javascripten?
BAN BEN: - Igen. Küldés előtt tömörítjük...
AG: - De ez szöveg... Általánosságban elmondható, hogy egy megabájt sok, de ez minden (a teljes futásidő megvan). Ezután megírja a saját üzleti logikáját, amely 1%-kal növeli a bináris értéket. Egyelőre nem látom, hogy megölné a frontendet. Sőt, a Web Assembly gyorsabban fog működni, mint a Javascript nyilvánvaló okból – nem kell elemezni.
BAN BEN: - Eddig egy vitatott pont ... Még mindig nincs referencia megvalósítása "Wasma" (Web Assembly), így egyértelműen megítélhető. Koncepcionálisan igen: mindannyian megértjük, hogy a binárisnak gyorsabbnak kell lennie, de ugyanaz a V8 jelenlegi megvalósítása nagyon hatékony.
AG: - Igen.
BAN BEN: - Az ottani összeállítás nagyon jól működik, és nem tény, hogy nagy előnye lesz.
AG: - A Web Assembly-t is nagyfiúk készítik.
BAN BEN: - Eddig úgy tűnik számomra, hogy még nehéz megítélni a Web Assemblyt. Hosszú évek óta folynak a tárgyalások, de kevés az igazi eredmény, amit érezni lehet.
AG: - Talán. Lássuk.
BAN BEN: – Nincsenek problémáink a háttérben… Lehet, hogy ezeket a problémákat a frontendben kellene hagynunk? Minek oda menni?
AG: - Meg kell tartanunk az élvonalbeliek személyzetét.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com