Alexey Grachev: Go Frontend

Kyiv Go Meetup Mai 2018:

Moderaator: – Tere kõigile! Aitäh, et olete siin kohal! Täna on meil kaks ametlikku esinejat – Lёša ja Vanya. Kui meil on piisavalt aega, tuleb veel kaks. Esimene esineja on Aleksei Gračёv, kes räägib meile GopherJS-ist.

Aleksei Gračёv (edaspidi – AG): – Ma olen Go-arendaja ja teen veebiteenuseid Go-s. Mõnikord tuleb mul tegeleda ka front-endiga, vahel pean sinna ise käega kallale minema. Soovin rääkida oma kogemusest ja uuringutest Go-s front-endis.

Legendi kohaselt: esmalt räägime, miks me tahame Go-d front-endis käivitada, ja seejärel räägime, kuidas seda teha. On kaks teed – Web Assembly ja GopherJS. Vaatame, millises seisus need lahendused on ja mida on võimalik teha.

Mis on valesti front-endiga?

Kas kõik on nõus, et front-end on hästi korras?

Testid on vähesed? Aeglane koostamine? Ökosüsteem? Hästi.

Front-endi kohta meeldib mulle tsitaat, mille ütles üks front-end arendajatest oma raamatus:

Javascriptis puudub tüübihüvitise süsteem. Nüüd hakkan mainima probleeme, millega olen oma töös kokku puutunud, ja selgitan, kuidas neid lahendatakse.

Tüübihüvitise süsteemi on raske nimetada tüübihüvitise süsteemiks Javascriptis – seal on stringid, mis tähistavad objekti tüüpi, kuid see ei ole tegelikult omavahel seotud tüüpidega. See probleem on lahendatud TypeScriptis (Javascripti pealiskihis) ja Flow-s (Javascripti tüüpide staatiline kontrollija). Tegelikult on front-end juba jõudnud lahenduseni Javascripti kehva tüübihüvitise probleemi osas.

Brahvis pole sellist standardset teeki olemas – seal on mõned sisseehitatud objektid ja "maagilised" funktsioonid brauserites. Kuid Javascriptis puudub selline standardne teek. See probleem lahendati kunagi jQuery abil (kõik kasutasid jQuery-d koos kõigi prototüüpide, abifunktsioonide ja funktsioonidega, mis on tööks vajalikud). Praegu kasutab kõik Lodashi:

Callback-i põrgu. Arvan, et kõik on näinud koodi Javascriptis umbes 5 aastat tagasi, ja see nägi välja nagu "nuudli" imeline hargnemine callbackidest. Nüüd on see probleem lahendatud (koos ES-15 või ES-16 tulekuga), Javascriptisse on lisatud lubadused (promises) ja kõik saavad hetkeks kergemalt hingata.

Kuni Promice-i põrguni… Ei tea, kuidas front-end tööstus suudab, aga nad ajavad end pidevalt kummalistesse olukordadesse. Nad suutsid teha põrgu ka "lubadustes". Seejärel lahendati probleem, lisades uue primaadi – async/await:

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

Milline probleem on lahendamata? Geomeetrilise progressiooniga kasvavad raamistikud, ökosüsteemi keerukus ja programmeerimine ise.

• JavaScripti süntaks on veidi kummaline. Me kõik teame muresid massiivi ja objekti liitmisega ning teisi nalju.
• JavaScript on mitme paradigma keel. Praegu on see eriti aktuaalne süsteem, kui ökosüsteem on väga suur:
  • kõik kirjutavad erinevates stiilides – mõned kirjutavad strukturaalselt, mõned funktsionaalselt, erinevad arendajad kirjutavad erinevalt;
  • erinevatest paketidest erinevad paradigmata, kui kasutate erinevaid pakette;
  • funktsionaalse programmeerimisega seondub JavaScriptis palju "nalja" – välja tuli rambda teek ja nüüd ei suuda keegi lugeda selle teegi raames kirjutatud programme.

• See kõik toob ökosüsteemi suurte mõjude, ja see on uskumatu suurenenud. Paketid ei ühildu omavahel: mõned kasutavad lubadusi, teised async/await, mõned kolmanda osapoole funktsioonide põhjal. Ja nad kirjutavad ka erinevates paradigmas!
• See viib selleni, et projekti on raske toetada. Vigade leidmine on keeruline, kui te ei suuda koodi lugeda.

Mis on Web Assembly?

Julged vennad Mozilla Fondist ja mitmetest teistest ettevõtetest tulid välja sellise asjaga nagu Web Assembly. Mis see on?

• See on brauserisse sisseehitatud virtuaalmasin, mis toetab binaarset formaati.
• Binaarsed programmid jõuavad sinna, neid täidetakse praktiliselt natiivselt, see tähendab, et brauser ei pea iga kord kogu JavaScripti „nuudlit“ parsiima.
• Kõik brauserid on väljendanud toetust.
• Kuna see on baitkood, võib mis tahes keele jaoks kirjutada kompilaatori.
• Neli peamist brauserit juba toetavad Web Assembly't.
• Peagi ootame natiivset tuge Go jaoks. Selline uus arhitektuur on juba lisatud: GOARCH=wasm GOOS=js (varsti). Praegu, nagu ma aru saan, ei ole see funktsionaalne, kuid on teadaanne, et see kindlasti tuleb Go'sse.

Mida teha praegu? GopherJS

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

• Go kood transpileeritakse „puhtaks“ JavaScriptiks.
• Käivitub kõikides brauserites - seal pole uusi funktsioone, mida toetavad ainult uuemad brauserid (see on Vanilla JS, mis töötab igal pool).
• Peaaegu kõik, mis Go-s on, on toetatud, sealhulgas gorutiinid ja kanalid… – kõik, mida me armastame ja tunneme.
• Peaaegu kogu standardraamatukogu on toetatud, välja arvatud need paketid, mille toetamine brauseris pole mõttekas: syscall, võrguvahetused (on net/http klient, kuid ei ole serverit, klient simuleeritakse läbi XMLHttpRequest). Üldiselt on kogu standardraamatukogu saadaval – siin see on brauseris, siin on stdlib Go, mida me armastame.
• Go paketi kogu ökosüsteem, kõik kolmanda osapoole lahendused (mallide loomine jne) saab kompileerida GopherJS-i abil ja seda brauseris käivitada.

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

Siin on selline väike tervitamine…

…Tavaline Go programm, tavaline fmt standardraamatukogu ja JavaScripti sidumine, et pääseda brauseri API-le. Println muudetakse lõpuks konsoli logiks ja brauser kirjutab “Tere, gopherid”! Nii lihtne: teeme GopherJS build – käivitame brauseris – kõik töötab!

Mis praegu olemas on? Sidumised

On sidumised kõigi populaarsete js-raamistikega:

• JQuery;
• Angular.js;
• D3.js graafikute loomise ja suurte andmete töötlemiseks;
• React.js;
• VueJS;
• isegi Electroni tugi (st juba praegu saame kirjutada lauaarvuti rakendusi "Electronis");
• ja kõige huvitavam – see on WebGL (saame teha täisgraafilisi rakendusi, sealhulgas mänge 3D-graafikaga, muusika ja kõigi häid asjadega);
• ja väga palju muid sidumisi kõigi populaarsete javascript-raamistike ja -raamatukogudega.

Raamistik

1. On juba loodud spetsiaalselt GopherJS-le veebiraamistik – Vecty. See on täieõiguslik React.js analoog, kuid ainult Go-s välja töötatud, GopherJS-i spetsiifikaga.
2. On mänguraamatud (üllatavalt!). Leidsin kaks kõige populaarsemat:
   • Engo;
   • Ebiten.

Demonstreerin paar näidet, kuidas see välja näeb ja mida juba praegu Go-s kirjutada saab:

Või selline variant (3D-shooterit ei leidnud, kuid ehk see eksisteerib):

Mida ma pakun?

Praegu on esikülje tööstus sellises seisus, et sinna tõttavad kõik keeled, mis varem hädas olid Javascriptiga. Nüüd kompileeritakse kõik “Web Assembly” juurde. Mida meil on vaja, et seal väärikas koht võtta kui “gopherid”?

Go on traditsiooniliselt, et see on süsteemide programmeerimiskeel ja praktiliselt pole ühtegi teeki kasutajaliidese jaoks. Midagi on olemas, kuid see on osaliselt hüljatud ja osaliselt mittefunktsionaalne.

Ja siin on hea võimalus luua Go-s kasutajaliidese teeke, mis töötavad GopherJS-il! Lõpuks saab kirjutada oma raamistiku! On aeg kirjutada raamistiku, mis on üks esimesi ja saab varajase kohandamise ning sina oled täht (kui see raamistiku on hea).

Saab kohandada palju erinevaid pakette, mis juba on Go ökosüsteemis, brauseri spetsiifika jaoks (näiteks mallide mootor). Need töötavad juba, saab luua mugavaid wrapper'eid, et saaks hõlpsasti sisu otse brauseris renderdada. Pluss, saa teha näiteks teenuse, mis oskab renderdada samu asju serveris ja frontendis, kasutades sama koodi – just nii, nagu frontendi arendajad armastavad (ainult et nüüd Go-s).

Saab kirjutada mängu! Lihtsalt lõbu pärast…

Minu poolt kõik.

Küsimused

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

AG: – Sa kirjutad Go gorutine, kanalid, struktuurid, umbrohustamine – kõik… Sa tellid sündmuse, edastad sinna funktsiooni.

K: – Kas ma siis kirjutan 'puhtas' Js-is?

AG: – Ei, sa kirjutad nagu Go-s ja ühendatud API-ga brauseris (API on samasugune). Sa saad kirjutada oma wrapper'id, et kanalisse tuleksid sõnumid – see pole keeruline.

K: – Kuidas mobiiliga?

AG: – Ma olen kindlasti näinud: on Cordova jaoks sidumisi, mida Js käivitab. React Native'i kohta ei tea; võib-olla on, aga võib-olla pole (ei huvitanud eriti). Mängumootor N-go toetab ka mobiilirakendusi – nii iOS-i kui Androidi.

K: – Küsimus Web Assembly kohta. Ruumi võtab järjest rohkem, vaatamata kompaktimisele, 'zippimisele'… Kas me tapame niimoodi frontendi maailma veel rohkem?

AG: – Web Assembly on binaarvormaat ja binaarne ei saa vaikimisi lõppversioonis olla suurem kui tekst… Sul on meeles runtime, kuid see on sama, mis standardse JavaScripti teegi toomine, kui seda ei ole, seega kasutame mingit Lodashi. Ma ei tea, kui palju Lodash võtab.

K: – Kindlasti vähem kui runtime…

AG: – 'Puhtas' Javascriptis?

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

AG: – Aga see on tekst… Ühesõnaga, megabait on nagu palju, aga see on – kõik (sul on kogu runtime). Seejärel kirjutad oma äri-logika, mis suurendab sinu binaari 1% võrra. Seni ei näe ma, et see frontendi tapaks. Eriti arvestades, et Web Assembly töötab kiiremini kui Javascript, ilmselge põhjuse tõttu – seda ei pea parsima.

K: – Hetkel on see vaieldav punkt… Veel ei ole mingit standardset elluviimist „Vasmast“ (Web Assembly), et saaks üheselt otsustada. Kontseptuaalselt – jah: me kõik mõistame, et binaar peaks olema kiirem, aga praegune elluviimine, nagu V8, on väga tõhus.

AG: – Jah.

K: – Kompileerimine töötab seal tõeliselt hästi ja pole kindel, et suur eelis tuleb.

AG: – Web Assembly'ga tegelevad ka suurte ettevõtete tegijad.

K: – Hetkel tundub, et Web Assembly kohta on veel keeruline otsustada. Juba aastaid on räägitud, aga reaalseid saavutusi, mida saaks katsuda, on vähe.

AG: – Võib-olla. Oleme vaatamas.

K: – Meil pole probleeme backendis… Kas oleks parem jätta need probleemid frontendisse? Miks sinna vägisi minna?

AG: – Peame hoidma frontendi spetsialiste.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level 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 jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com