Kyiv Go Meetup mai 2018:
Moderaator: - Tere kõigile! Aitäh, et olete siin! Täna on meil kaks ametlikku esinejat - Lyosha ja Vanya. Kui meil on piisavalt aega, tuleb neid veel kaks. Esimene esineja on Alexey Grachev, ta räägib meile GopherJS-ist.
Aleksei Gratšev (edaspidi – AG): – Olen Go arendaja ja kirjutan Go-s veebiteenuseid. Mõnikord peate tegelema frontendiga, mõnikord peate sellesse käsitsi sisenema. Tahan rääkida oma kogemusest ja uurimistööst, mis puudutavad Go on the frontendi.
Legend on järgmine: kõigepealt räägime sellest, miks tahame Go't esiotsas käivitada, seejärel räägime sellest, kuidas seda teha. On kaks võimalust – Web Assembly ja GopherJS. Vaatame, mis seisus need lahendused on ja mida saab teha.
Mis frontendil viga on?
Kas kõik nõustuvad, et frontendiga on kõik korras?
Kas teste pole piisavalt? Aeglane ehitus? Ökosüsteem? Hästi.
Mis puudutab esiosa, siis mulle meeldib tsitaat, mille üks kasutajaliidese arendaja oma raamatus ütles:
Javascriptil pole tüübisüsteemi. Nüüd nimetan probleemid, millega töö käigus kokku puutusin, ja selgitan, kuidas need lahenevad.
Tüübisüsteemi üldiselt ei saa Javasriptis tüübisüsteemiks nimetada - seal on read, mis näitavad objekti tüüpi, kuid tegelikult pole sellel tüüpidega mingit pistmist. Selle probleemi lahendab TypeScript (Javasripti lisandmoodul) ja Flow (Javascripti staatilise tüübi kontrollija). Tegelikult on frontend juba jõudnud Javascripti halva tüüpi süsteemi probleemi lahendamiseni.
Brauseris ei ole standardset teeki - brauserites on mõned sisseehitatud objektid ja "võlu" funktsioonid. Kuid Javascriptis pole standardset teeki kui sellist. Selle probleemi lahendas juba korra jQuery (kõik kasutasid jQueryt koos kõigi prototüüpide, abimeeste, funktsioonidega, mida tööks vaja oli). Nüüd kasutavad kõik Lodashi:
Tagasihelistamise põrgu. Ma arvan, et kõik nägid Javascripti koodi umbes 5 aastat tagasi ja see nägi välja nagu tagasihelistamiste uskumatu keerukusega nuudel. Nüüd on see probleem lahendatud (ES-15 või ES-16 väljatulekuga), Javascriptile on lisatud lubadusi ja kõik saavad korraks kergemalt hingata.
Kuni Promice põrgu saabus... Ma ei tea, kuidas esiotsa tööstus hakkama saab, aga nad ajavad end alati mingisse kummalisse džunglisse. Meil õnnestus ka lubadusi täita. Seejärel lahendasime selle probleemi, lisades uue primitiivi - async/await:
Asünkroonsuse probleem on lahendatud. Async/await on erinevates keeltes üsna populaarne primitiiv. Pythonil ja teistel on selline lähenemine - see on üsna hea. Probleem lahendatud.
Mis probleem ei lahene? Raamistikute eksponentsiaalselt kasvav keerukus, ökosüsteemi ja programmide endi keerukus.
- Javascripti süntaks on veidi kummaline. Me kõik teame probleeme massiivi ja objekti lisamisega ja muude naljadega.
- Javascript on mitme paradigmaga. See on eriti pakiline süsteem praegu, kui ökosüsteem on väga suur:
- kõik kirjutavad erinevas stiilis – mõni kirjutab struktuurselt, mõni funktsionaalselt, erinevad arendajad kirjutavad erinevalt;
- erinevatest pakettidest, erinevatest paradigmadest, kui kasutate erinevaid pakette;
- Javasriptis on funktsionaalse programmeerimisega palju nalja - ilmus rambda teek ja nüüd ei saa keegi selles teegis kirjutatud programme lugeda.
- Kõik see avaldab ökosüsteemile suurt mõju ja see on uskumatult kasvanud. Paketid ei ühildu omavahel: osad põhinevad lubadustel, osad asünkroonil/ootamisel, osad tagasihelistustel. Nad kirjutavad ka erinevates paradigmades!
- See muudab projekti hooldamise keeruliseks. Kui te ei saa koodi lugeda, on viga raske leida.
Mis on Web Assembly?
Mozilla Foundationi ja mitmete teiste ettevõtete vaprad poisid tulid välja sellise asjaga nagu Web Assembly. Mis see on?
- See on brauserisse sisseehitatud virtuaalne masin, mis toetab binaarvormingut.
- Binaarprogrammid jõuavad sinna ja neid käivitatakse peaaegu natiivselt, see tähendab, et brauser ei pea iga kord kõiki javascripti koodi nuudleid sõeluma.
- Kõik brauserid on toetanud.
- Kuna see on baitkood, saate kompilaatori kirjutada mis tahes keele jaoks.
- Neli suuremat brauserit on juba varustatud Web Assembly toega.
- Ootame peagi Go's kohalikku tuge. See uus arhitektuur on juba lisatud: GOARCH=wasm GOOS=js (varsti). Siiani, nagu ma aru saan, ei ole see funktsionaalne, kuid on väide, et see on kindlasti Go-s.
Mida teha nüüd? GopherJS
Kuigi meil ei ole Web Assembly tuge, on olemas selline transpiler nagu GopherJS.
- Go kood muudetakse puhtaks Javascriptiks.
- Töötab kõigis brauserites - pole uusi funktsioone, mida toetaksid ainult kaasaegsed brauserid (see on Vanilla JS, mis töötab kõigega).
- Tugi on peaaegu kõigele, mis Go'l on, sealhulgas gorutiinidele ja kanalitele... kõigele, mida me nii väga armastame ja teame.
- Toetatud on peaaegu kogu standardne teek, välja arvatud need paketid, mida pole mõtet brauseris toetada: syscall, netinteraktsioonid (neti/http-klient on olemas, kuid serverit pole ja klienti emuleeritakse XMLHttpRequesti kaudu). Üldiselt on saadaval kogu standardne teek - siin on see brauseris, siin on Go stdlib, mida me armastame.
- Kogu paketi ökosüsteemi Go-s, kõiki kolmanda osapoole lahendusi (mallid jne) saab GopherJS-i abil kompileerida ja brauseris käivitada.
GopherJS-i on väga lihtne hankida – see on lihtsalt tavaline Go pakett. Me võtame ja meil on GopherJS-i käsk rakenduse loomiseks:
See on nii väike tere maailm...
...Tavaline Go programm, tavaline standardteegi fmt pakett ja Binding Js brauseri API-ni jõudmiseks. Println teisendatakse lõpuks konsooli logiks ja brauser kirjutab "Tere, gophers"! Nii lihtne see ongi: loome GopherJS-i – käivitame selle brauseris – kõik töötab!
Mis sul hetkel on? Köited
Kõigi populaarsete js-i raamistike jaoks on köited:
- JQuery;
- Angular.js;
- D3.js suurandmete joonistamiseks ja nendega töötamiseks;
- React.js;
- VueJS;
- on isegi Electroni tugi (st saame juba Electronis töölauarakendusi kirjutada);
- ja kõige naljakam on WebGL (saame teha täisgraafilisi rakendusi, sh 3D-graafika, muusika ja kõige paremaga mänge);
- ja paljud muud sidumised kõigile populaarsetele JavaScripti raamistikele ja teekidele.
Raamistik
- Spetsiaalselt GopherJS-i jaoks on juba välja töötatud veebiraamistik - Vecty. See on React.js-i täisväärtuslik analoog, kuid see on välja töötatud ainult Go-s ja GopherJS-i spetsiifikaga.
- Mängukotid on olemas (üllatus!). Leidsin kaks kõige populaarsemat:
- Engo;
- Ebiten.
Näitan teile paari näidet selle kohta, kuidas see välja näeb ja mida saate juba Go-sse kirjutada:
Või see valik (ma ei leidnud 3D-laskjat, kuid võib-olla on see olemas):
Mida ma pakun?
Nüüd on esiotsa tööstus sellises seisus, et kõik keeled, mis varem Javascriptist nutsid, tormavad sinna. Nüüd koondatakse kõik veebikomplektidesse. Mida me vajame, et võtta seal oma õige koht Gopheritena?
Go on traditsiooniliselt eeldanud, et see on süsteemi programmeerimiskeel ja kasutajaliidesega töötamiseks raamatukogusid praktiliselt pole. Midagi on, aga see on pooleldi mahajäetud, pooleldi mittetoimiv.
Ja nüüd on hea võimalus teha Go-s kasutajaliidese teeke, mis töötavad GopherJS-is! Lõpuks saate kirjutada oma raamistiku! See on aeg, mil saate kirjutada raamistiku ja see on üks esimesi ja saab varakult kasutusele ning olete staar (kui see on hea raamistik).
Saate kohandada palju erinevaid juba Go ökosüsteemis olevaid pakette vastavalt brauseri spetsiifikale (näiteks Template engine). Need juba töötavad, saate teha mugavaid köiteid, et saaksite sisu hõlpsalt otse brauseris renderdada. Lisaks saate teha näiteks teenuse, mis suudab sama koodi abil renderdada sama asja nii serveris kui ka esiotsas – kõike, mis esiotsa arendajatele meeldib (ainult nüüd Go-s).
Saate kirjutada mängu! Lihtsalt lõbu pärast…
See on kõik, mida ma öelda tahtsin.
küsimused
Küsimus (edaspidi Q): – Kas ma kirjutan Go või Js keeles?
AG: – Kirjutate rutiine, kanaleid, struktuure, manustamist – kõike Go-s... Tellite sündmuse, edastate seal funktsiooni.
Sisse: – Nii et ma kirjutan "alasti" Js-iga?
AG: – Ei, kirjutate nagu Go ja loote ühenduse brauseri API-ga (API pole muutunud). Saate kirjutada oma sidemed, nii et sõnumid saadetakse kanalile - see pole keeruline.
Sisse: – Kuidas on lood mobiiliga?
AG: – Nägin kindlasti: Cordova plaastri jaoks on olemas köited, mida Js jookseb. In React Native – ma ei tea; võib-olla on, võib-olla mitte (ma ei olnud eriti huvitatud). N-go mängumootor toetab mõlemat mobiilirakendust – nii iOS-i kui ka Androidi.
Sisse: – Küsimus Web Assembly kohta. Üha rohkem ruumi võetakse, vaatamata kokkusurumisele ja “tõmblukule”... Kas me ei tapa esiotsa maailma sel moel veelgi enam?
AG: – Web Assembly on binaarvorming ja vaikimisi ei saa binaarvormingus lõppväljaandes olla rohkem kui tekst... Teid tõmbab käitusaeg, kuid see on sama, mis standardse Javascripti teegi lohistamine, kui seda seal pole, nii et me kasuta Lodashit. Ma ei tea, kui palju Lodash võtab.
Sisse: – Ilmselgelt vähem kui käitusaeg...
AG: – „Puhas” Javascriptis?
Sisse: - Jah. Tihendame selle enne saatmist...
AG: – Aga see on tekst... Üldiselt tundub megabait olevat palju, aga see on ka kõik (teil on kogu käitusaeg). Järgmisena kirjutate oma äriloogika, mis suurendab teie kahendkoodi 1% võrra. Siiani ma ei näe, et see esiotsa tapaks. Veelgi enam, Web Assembly töötab selgel põhjusel kiiremini kui Javascript – seda pole vaja sõeluda.
Sisse: – See on endiselt vastuoluline punkt... “Vasma” (Veebikogu) viideteostust veel pole, et saaks üheselt hinnata. Kontseptuaalselt jah: me kõik mõistame, et binaarne peaks olema kiirem, kuid sama V8 praegune rakendamine on väga tõhus.
AG: - Jah.
Sisse: - Sealne koostamine töötab tõesti väga lahedalt ja pole tõsiasi, et sellel oleks suur eelis.
AG: – Web Assemblyt teevad ka suured mehed.
Sisse: – Mulle tundub, et Web Assemblust on endiselt raske hinnata. Vestlusi on olnud juba palju aastaid, kuid reaalseid saavutusi on vähe tunda.
AG: - Võib olla. Me näeme.
Sisse: – Meil pole taustasüsteemis probleeme... Võib-olla peaksime need probleemid frontendisse jätma? Miks sinna minna?
AG: – Peame hoidma eesliinitöötajaid.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com