Aleksei Gračev: Go Frontend

Kyiv Go Meetup Mai 2018:

Esitleja: – Tere kõigile! Aitäh, et tulite! Täna on meil kaks ametlikku esinejat – Ljoša ja Vanya. Kui aega jääb, on veel kaks. Esimene esineja on Aleksei Grachyov, kes räägib meile GopherJS-st.

Aleksei Grachyov (edaspidi – AG): – Olen Go-arendaja ja kirjutan veebiteenuseid Goga. Mõnikord tuleb mul tegeleda ka frontendiga, vahel tuleb sealt käsitsi sekkuda. Soovin jagada oma kogemust ja uurimusi Go-st frontendis.

Legend on selline: alustame vestlust, miks me soovime Go-d frontendis käivitada, seejärel arutame, kuidas seda teha. On kaks teed – Web Assembly ja GopherJS. Vaatame, millises seisundis need lahendused on ja mida saab teha.

Mis on valesti frontendiga?

Kas kõik on nõus, et frontendis on kõik hästi?

Testide puudumine? Aeglane kogumine? Ökosüsteem? Hea küll.

Frontendist rääkides meeldib mulle üks tsitaat, mille ütles üks frontend-arendaja oma raamatutes:

Javascriptis ei ole tüübivõimet. Nüüd hakkan nimetamisi probleeme, millega ma oma töös kokku puutusin, ja selgitama, kuidas neid lahendatakse.

Tüübivõimet on tegelikult raske nimetada tüübivõimete süsteemiks Javascriptis – seal on stringid, mis tähistavad objekti tüüpi, kuid tegelikult pole sellel tüüpidega mingit seost. Selle probleemi lahendas TypeScript (Javascripti pealisehitust) ja Flow (Javascripti staatiline kontrollija). Frontend on juba jõudnud lahendama Javascripti halva tüübivõime süsteemi probleemi.

Brahvtifoodust standardset raamatukogu ei ole – on mõned sisseehitatud objektid ja „maagilised“ funktsioonid brauserites. JavaScriptis puudub standardne raamatukogu. Selle probleemi lahendas kunagi jQuery (kõik kasutasid jQuery-d koos kõigi prototype’ide, abifunktsioonide ja funktsioonidega, mida oli vaja kasutada). Nüüd aga kõik kasutavad Lodashi:

Callback hell. Arvan, et kõik on näinud Javascripti koodi umbes viis aastat tagasi, ja see nägi välja nagu „nuudli” jahtum, mis koosneb uskumatust callbackide äärimisest. Nüüd on see probleem lahendatud (ES-15 või ES-16 ilmumisega), Javascripti on lisatud lubadused (promises) ja kõik hingavad mõnda aega kergemalt.

Kuni tuleb Promise hell... Ma ei tea, kuidas frontenditööstus suudab, aga nad venduvad end igasugustesse kummalistesse jamadesse. Nad suutsid isegi „lubadustel” teha helli. Hiljem lahendati see probleem, lisades uue primitiivi – async/await:

Asünkroonsuse probleem on lahendatud. Async/await – on üsna populaarne primitiiv erinevates keeltes. Pythonis ja muudes keeltes on selline lähenemine olemas – see on väga hea. Probleem on lahendatud.

Milline probleem ei ole lahendatud? Geomeetriliselt kasvav keerukus raamistike, ökosüsteemi ja tegelikult programmide osas.

• Javascripti süntaks on veidi kummaline. Kõik teame probleeme massiivi ja objekti liitmisel ja muid nalju.
• Javascript on mitme paradigma süsteem. Praegu on see eriti aktuaalne, kus ökosüsteem on väga suur:
  • kõik kirjutavad erinevates stiilides – keegi kirjutab struktuurselt, keegi kirjutab funktsionaalset, erinevad arendajad kirjutavad erinevalt;
  • erinevatest pakettidest (packages) erinevad paradigmareeglid, kui kasutate erinevaid pakette;
  • on palju „meelelahutust” funktsionaalses programmeerimises Javascriptis – ilmus raamatukogu rambda ja nüüd ei suuda keegi lugeda selle raamatukogus kirjutatud programme.

• See kõik toob ökosüsteemile suure mõju ja see on tohutult kasvanud. Paketid ei ühildu üksteisega: keegi - lubadustel, keegi - async/await-s, keegi - callbackidel. Lisaks kirjutavad ja erinevates paradigmades!
• See viib selleni, et projekti on keeruline toetada. Raskendat on leida tõrge, kui te ei suuda koodi lugeda.

Mis on Web Assembly?

Tublid poisid Mozilla Foundationist ja mitmest muust ettevõttest mõtlesid välja midagi sellist nagu Web Assembly. Mis see on?

• See on brauseris sisseehitatud virtuaalne masin, mis toetab binaarset formaati.
• Binaarsed programmid saadetakse sinna, need täidetakse praktiliselt natiivsete võimalustega, mis tähendab, et brauser ei pea iga kord kogu „nuudli” Javascripti koodi parsima.
• Kõik brauserid on kinnitanud toetust.
• Kuna see on baidikood, on võimalik kirjutada kompilaator mistahes keele jaoks.
• Neli peamist brauserit on juba varustatud Web Assembly toe.
• Peagi ootame Go loomulikku tuge. Selline uus arhitektuur on juba lisatud: GOARCH=wasm GOOS=js (peagi). Seni, nagu ma mõistan, ei ole see funktsionaalne, kuid on avaldatud teadet, et see kindlasti tuleb Go-sse.

Mida praegu teha? GopherJS

Kuna meil ei ole Web Assembly tuge, on olemas selline transpiler nagu GopherJS.

• Go kood transpileerub „puhtaks” Javascriptiks.
• Käivitatakse kõikides brauserites – seal ei ole uusi funktsioone, mida toetavad ainult kaasaegsed brauserid (see on Vanilla JS, mis töötab kõiges, mis tahes seadmes).
• Peaaegu kõik Go omadused, sealhulgas gorutiinid ja kanalid, on toetatud… – kõik, mida me armastame ja tunneme.
• Peaaegu kogu standardteek on toetatud, välja arvatud need paketid, millel pole mõtet brauseris töötada: syscall, neti suhtlemine (olemas on net/http klient, kuid serverit pole, klient emuleeritakse läbi XMLHttpRequest). Kokkuvõttes on kogu standardteek saadaval – siin see on brauseris, siin on stdlib Go, mida me armastame.
• Kogu Go paketi ökosüsteemi, kõik kolmandate osapoolte lahendused (mallid jne) saab kompileerida GopherJS-iga ja käivitada seda brauseris.

GopherJS-i hankimine on väga lihtne – see on tavaline Go-pakett. Teeme go get ja meil on GopherJS käsk, et rakendust ehitada:

Siin on selline väike hello world...

...Tavaline Go programm, tavaline fmt paketist standardteegist ja Binding Js, et brauseri API-le ligi pääseda. Println muudetakse lõpuks console logiks ja brauser kirjutab 'Hello gophers'! Nii lihtne: teeme GopherJS build – käivitame brauseris – kõik töötab!

Mis on hetkel saadaval? Bindings

On bindingeid kõigile populaarsetele js-raamistikele:

• JQuery;
• Angular.js;
• D3.js graafikute ja suurte andmete töötlemiseks;
• React.js;
• VueJS;
• isegi on olemas tugi Electron'ile (praegu saame kirjutada lauaarvuti rakendusi 'Elecron'iga);
• ja kõige huvitavam – see on WebGL (saame teha graafikarakendusi, sealhulgas 3D-mänge, muusikat ja kõike muud vajalikku);
• ja väga palju muid bindingeid kõikidele populaarsetele JavaScripti raamistikutele ja teekidele.

Framework

1. GopherJS-ile on juba välja töötatud spetsiaalne veebiraamistik – Vecty. See on täisfunktsionaalne analoog React.js-ile, kuid loodud Go keeles, GopherJS spetsiifikaga.
2. On ka mänguteeke (üllatus!). Leidsin kaks populaarseimat:
   • Engo;
   • Ebiten.

Kannan paar näidet sellest, kuidas see välja näeb ja mida on juba võimalik Go-s kirjutada:

Või selline variant (3D-laskurite mängu ei leidnud, kuid võib-olla on see olemas):

Mida ma ettepanen?

Praegu on frontend-tööstus sellises seisus, et igasugused keeled, mis varem nutsid JavaScripti pärast, tormavad sinna sisse. Nüüd kompileeritakse kõik 'Web Assembly'. Mida me vajame, et seal 'gofiri' väärikas koht leida?

Go keeles on traditsiooniliselt arvatud, et see on süsteemi programmeerimiskeel, ja praktiliselt puuduvad UI jaoks raamatukogud. Midagi on, kuid need on poolik, poolik funktsionaalne.

Ja nüüd on hea võimalus luua Go-s UI raamatukogud, mis töötavad GopherJS-is! Saame lõpuks kirjutada oma raamistikku! On see aeg, mil saame kirjutada raamistikku ja see saab olema üks esimesi ning omandab varajase kohandamise ning sina oled staar (kui see raamistik on hea).

Saame kohandada palju erinevaid pakette, mis juba on Go ökosüsteemis, brauseri spetsiifiliseks (nt mallimootor). Need hakkavad töötama, saame mugavad ümberringed teha, et sisu oleks kerge brauseris renderdada. Pluss, saame teha näiteks teenuse, mis oskab renderdada sama serveris ja frontendis, kasutades sama koodi – just nii nagu frontend-arendajad armastavad (ainult nüüd Go-s).

Võime kirjutada mängu! Just for fun...

Mul on kõik.

Küsimused

Küsimus (edasi – K): – Kas ma kirjutan Go-s või Js-is?

AG: – Sa kirjutad Go rutaanide, kanalite, struktuuride, embedding – kõike… Sa tellid event'i, edastad sinna funktsiooni.

K: – Kas see tähendab, et ma kirjutan 'puhtas' Js-is?

AG: – Ei, sa kirjutad nagu Go-s ja ühendud brauseri API-ga (API ei ole muudetud). Sa saad kirjutada oma ümberringed, et kanalisse tuleksid sõnumid – see ei ole keeruline.

K: – Kuidas on mobiiliga?

AG: – Olen kindlasti näinud: on olemas bindingeid Cordova patch'i jaoks, mida Js käivitab. React Native – ei tea; võib-olla on, aga võib-olla ei ole (ei ole eriti uurinud). Mängu mootor N-go toetab ka mobiilirakendusi – nii iOs kui Android.

K: – Küsimus Web Assembly kohta. Ruumi on aina rohkem, vaatamata kompressioonile, 'zipped'… Kas me ei hävita sellega frontendmaailma veelgi rohkem?

AG: – Web Assembly on binaarne formaat ja binaarne ei saa vaikimisi lõppversioonis olla suurem kui tekst… Teid tõukab runtime, kuid see on sama, mis JavaScripti standardteegi tõukamine, kui seda ei ole, seega kasutame mingit Lodashi. Ma ei tea, kui palju Lodash ruumi võtab.

K: – Kindlasti vähem kui runtime…

AG: – 'Puhtas' JavaScriptis?

K: – Jah. Me ju kompressime selle enne saatmist…

AG: – Aga see on ju tekst… Ühesõnaga, megabait on justkui palju, kuid see on kõik (sul on kogu runtime olemas). Edasi kirjutad oma äriloogika, mis suurendab sinu binaari 1%. Seni ma ei näe, et see hävitaks frontend'i. Eriti arvestades, et Web Assembly töötab kiiremini kui JavaScript ilmselge põhjuse tõttu – seda ei pea analüüsima.

K: – Veel pole veel selget teavet… Praegu ei ole mingit ideaalset rakendust "Web Assembly", et saaks üheselt hinnata. Kontseptuaalselt – jah: me kõik mõistame, et binaar peab olema kiirem, kuid praegune V8 rakendus on väga efektiivne.

AG: – Jah.

K: – Kompilleerimine töötab seal tõeliselt hästi ja ei ole kindel, et see toob kaasa suurt eelist.

AG: – Web Assembly't arendavad ka suured tegijad.

K: – Praegu on mulle tundunud, et Web Assembly kohta on veel vara hinnangut anda. Mitu aastat on juba räägitud, kuid reaalseid saavutusi, mida katsuda, on vähe.

AG: – Võib-olla. Jätkame jälgimist.

K: – Meil ei ole probleeme backend'is… Kas ei võiks neid probleeme jätta frontend'i? Miks peaks sinna sekkuma?

AG: – Peame hoidma fronthendi tiimi.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com