Kyiv Go Meetup toukokuu 2018:
Moderaattori: - Hei kaikki! Kiitos, että olet täällä! Tänään meillä on kaksi virallista puhujaa - Lyosha ja Vanya. Niitä tulee kaksi lisää, jos meillä on aikaa. Ensimmäinen puhuja on Alexey Grachev, hän kertoo meille GopherJS:stä.
Aleksei Grachev (jäljempänä - AG): – Olen Go-kehittäjä ja kirjoitan verkkopalveluita Golla. Joskus joutuu käsittelemään frontendiä, joskus kiivetä sinne kahvoilla. Haluan puhua kokemuksistani ja tutkimuksestani Go on frontendissä.
Legenda on seuraava: ensin puhumme siitä, miksi haluamme käyttää Goa käyttöliittymässä, sitten puhumme kuinka voimme tehdä sen. On olemassa kaksi tapaa - Web Assembly ja GopherJS. Katsotaan, missä tilassa nämä päätökset ovat ja mitä voidaan tehdä.
Mitä vikaa frontendissä on?
Ovatko kaikki samaa mieltä siitä, että käyttöliittymän kanssa kaikki on hyvin?
Vähän testejä? Hidas rakentaminen? Ekosysteemi? Hieno.
Mitä tulee käyttöliittymään, pidän lainauksesta, jonka yksi käyttöliittymän kehittäjistä sanoi kirjassaan:
Javascriptillä ei ole tyyppijärjestelmää. Nimeän nyt työssäni kohtaamani ongelmat ja selitän kuinka ne ratkaistaan.
Tyyppijärjestelmää on yleensä vaikea kutsua tyyppijärjestelmäksi Javascriptissä - siellä on rivejä, jotka osoittavat objektin tyypin, mutta itse asiassa tällä ei ole mitään tekemistä tyyppien kanssa. Tämä ongelma on ratkaistu TypeScriptillä (Javascriptin lisäosa) ja Flow:lla (Javascriptin staattinen tyyppitarkistus). Itse asiassa käyttöliittymä on jo mennyt niin pitkälle, että se on ratkaissut Javascriptin huonon tyyppisen järjestelmän ongelman.
Selaimessa ei sinänsä ole vakiokirjastoa - selaimissa on joitain sisäänrakennettuja objekteja ja "maagisia" toimintoja. Mutta minulla ei ole vakiokirjastoa Javascriptissä sellaisenaan. JQuery on jo ratkaissut tämän ongelman (kaikki käyttivät jQuerya kaikkien prototyyppien, apuohjelmien ja toimintojen kanssa, jotka tarvitsisivat toimia). Nyt kaikki käyttävät Lodashia:
takaisinsoitto helvetti. Luulen, että kaikki näkivät Javascript-koodin noin 5 vuotta sitten, ja se näytti "nuudelista" uskomattomista takaisinsoittojen monimutkaisuudesta. Nyt tämä ongelma on ratkaistu (ES-15:n tai ES-16:n julkaisun myötä), Javascriptiin lisättiin lupauksia ja kaikki alkoivat hengittää hetken aikaa.
Kunnes Promicen helvetti tuli... En tiedä miten etupään teollisuus pärjää, mutta he ajavat aina itsensä johonkin outoon viidakkoon. Onnistuimme myös tekemään helvettiä "lupauksille". Sitten ratkaisimme tämän ongelman lisäämällä uuden primitiivin - async / await:
Asynkronian avulla ongelma on ratkaistu. Async/await on melko suosittu primitiivinen eri kielillä. Pythonilla ja muilla on tämä lähestymistapa - se on tarpeeksi hyvä. Ongelma ratkaistu.
Mikä ongelma ei ratkea? Kehysten eksponentiaalisesti kasvava monimutkaisuus, ekosysteemin ja itse ohjelmien monimutkaisuus.
- Javascriptin syntaksi on hieman outo. Tiedämme kaikki ongelmat, jotka liittyvät taulukon ja objektin lisäämiseen ja muihin temppuihin.
- Javascript on moniparadigma. Nyt tämä on erityisen kiireellinen järjestelmä, kun ekosysteemi on erittäin suuri:
- jokainen kirjoittaa eri tyyleillä - joku kirjoittaa rakenteellisesti, joku toiminnallisesti, eri kehittäjät kirjoittavat eri tavalla;
- eri paketeista (paketeista) erilaisia paradigmoja, kun käytät erilaisia paketteja;
- paljon "hauskaa" toiminnallisella ohjelmoinnilla Javascriptissä - rambda-kirjasto ilmestyi ja nyt kukaan ei voi lukea tähän kirjastoon kirjoitettuja ohjelmia.
- Kaikella tällä on suuri vaikutus ekosysteemiin, ja se on kasvanut uskomattoman paljon. Paketit eivät ole yhteensopivia keskenään: jotkut ovat lupauksia, jotkut ovat async/wait-tilassa, jotkut ovat takaisinsoittoja. He myös kirjoittavat eri paradigmoissa!
- Tämä vaikeuttaa projektin ylläpitoa. On vaikea löytää vikaa, jos et osaa lukea koodia.
Mikä on Web Assembly?
Rohkeat kaverit Mozilla Foundationista ja useista muista yrityksistä keksivät sellaisen asian kuin Web Assembly. Mikä tämä on?
- Tämä on selaimeen sisäänrakennettu virtuaalikone, joka tukee binaarimuotoa.
- Binääriohjelmat pääsevät sinne, ne suoritetaan lähes natiivisti, eli selaimen ei tarvitse jäsentää kaikkia javascript-koodin "nuudeleita" joka kerta.
- Kaikki selaimet ovat ilmoittaneet tukevansa.
- Koska tämä on tavukoodi, voit kirjoittaa kääntäjän mille tahansa kielelle.
- Neljä suurta selainta toimitetaan jo Web Assembly -tuella.
- Odotamme Go pian natiivitukea. Tämä uusi arkkitehtuuri on jo lisätty: GOARCH=wasm GOOS=js (pian). Ymmärtääkseni se ei toistaiseksi ole toimiva, mutta on väite, että se tulee varmasti olemaan Gossa.
Mitä tehdä nyt? GopherJS
Vaikka meillä ei ole Web Assembly -tukea, on olemassa muuntaja, kuten GopherJS.
- Go-koodi muunnetaan "puhtaaksi" Javascriptiksi.
- Toimii kaikissa selaimissa - ei ole uusia ominaisuuksia, joita vain nykyaikaiset selaimet tukevat (tämä on Vanilla JS, joka toimii missä tahansa).
- Tukea on melkein kaikelle, mitä Gossa on, mukaan lukien gorutiinit ja kanavat... - kaikkea mitä rakastamme ja tiedämme niin paljon.
- Lähes koko vakiokirjasto on tuettu, lukuun ottamatta niitä paketteja, joita ei ole järkevää tukea selaimessa: syscall, net-vuorovaikutukset (on net / http-asiakas, mutta ei palvelinta, ja asiakasta emuloidaan XMLHttpRequestin kautta) . Yleensä koko vakiokirjasto on saatavilla - tässä se on selaimessa, tässä on Go stdlib, jota rakastamme.
- Go:n koko pakettiekosysteemi, kaikki kolmannen osapuolen ratkaisut (mallinnus jne.) voidaan kääntää GopherJS:llä ja ajaa selaimessa.
GopherJS:n hankkiminen on erittäin helppoa - se on vain tavallinen Go-paketti. Kokeilemme ja meillä on GopherJS-komento sovelluksen rakentamiseen:
Tässä on niin pieni hei maailma...
...Tavallinen Go-ohjelma, tavallinen fmt-paketti vakiokirjastosta ja Binding Js selaimen API:n saavuttamiseksi. Println muunnetaan lopulta konsolin lokiksi ja selain kirjoittaa "Hei gophers"! Se on niin yksinkertaista: rakennamme GopherJS:n - käynnistämme sen selaimessa - kaikki toimii!
Mitä siellä on tällä hetkellä? Sidokset
Kaikille suosituille js-kehyksille on olemassa sidoksia:
- jquery;
- Angular.js
- D3.js suurdatan piirtämiseen ja käsittelyyn;
- React.js
- VueJS;
- siellä on jopa tuki Electronille (eli voimme jo kirjoittaa työpöytäsovelluksia Electronille);
- ja hauskin asia on WebGL (voimme tehdä täysgrafisia sovelluksia, mukaan lukien 3D-grafiikkapelit, musiikki ja kaikki herkut);
- ja paljon muita sidoksia kaikkiin suosittuihin JavaScript-kehyksiin ja kirjastoihin.
Puitteet
- GopherJS:lle on jo kehitetty verkkokehys - Vecty. Tämä on täysimittainen React.js:n analogi, mutta kehitetty vain Gossa GopherJS:n ominaisuuksilla.
- Siellä on pelikassit (yhtäkkiä!). Löysin kaksi suosituinta:
- engo;
- Ebiten.
Esitän pari esimerkkiä siitä, miltä se näyttää ja mitä voidaan jo kirjoittaa Go:ssa:
Tai tämä vaihtoehto (en löytänyt 3D-ampujaa, mutta ehkä se on olemassa):
Mitä ehdotan?
Nyt käyttöliittymäteollisuus on sellaisessa tilassa, että kaikki kielet, jotka aiemmin huusivat Javascriptistä, ryntäävät sinne. Nyt kaikki käännetään "Web Assemblies"-muotoon. Mitä tarvitsemme ottamaan siellä arvokkaan paikan "gofereina"?
Gossa se on perinteisesti mennyt järjestelmän ohjelmointikieleksi, eikä käyttöliittymän kanssa työskentelyä varten ole käytännössä yhtään kirjastoa. Jotain on, mutta se on puoliksi hylätty, puoliksi toimimaton.
Ja nyt – hyvä tilaisuus tehdä Goissa käyttöliittymäkirjastoja, jotka toimivat GopherJS:llä! Voit vihdoin kirjoittaa oman kehyksesi! On tullut aika, jolloin voit kirjoittaa kehyksen, ja se on yksi ensimmäisistä ja otetaan käyttöön aikaisin, ja sinusta tulee tähti (jos se on hyvä kehys).
Voit mukauttaa monia erilaisia Go-ekosysteemissä jo olemassa olevia paketteja selaimen ominaisuuksiin (esimerkiksi Template-moottori). Ne toimivat jo, voit tehdä käteviä sidoksia, jotta voit helposti renderöidä sisältöä suoraan selaimessa. Lisäksi voit tehdä esimerkiksi palvelun, joka voi tuottaa saman asian palvelimella ja käyttöliittymässä käyttämällä samaa koodia – kaikkea mistä käyttöliittymäkehittäjät pitävät (vain nyt Gossa).
Voit kirjoittaa pelin! Huvin vuoksi…
Siinä kaikki, mitä halusin sanoa.
kysymykset
Kysymys (jäljempänä Q): – Kirjoitanko Go vai Js?
AG: – Kirjoitat rutiineja, kanavia, rakenteita, upottamista – kaikkea Gossa… Tilaat tapahtuman, välität siellä toiminnon.
in: - Eli kirjoitan "alastomiin" J:ihin?
AG: - Ei, kirjoitat ikään kuin Go ja muodostat yhteyden selaimen API:hen (sovellusliittymä ei ole muuttunut). Voit kirjoittaa omia sidoksia niin, että viestit tulevat kanavalle - se ei ole vaikeaa.
in: - Entä mobiili?
AG: - Näin varmaksi: Js:n julkaisemaan Cordova-korjaukseen on olemassa sideaineita. React Nativessa en tiedä; ehkä on, ehkä ei (ei erityisen kiinnostunut). N-go-pelimoottori tukee molempia mobiilisovelluksia - sekä iOS:itä että Androidia.
in: – Kysymys Web Assemblysta. Yhä useammat paikat ovat käytössä ytimekkyydestä, "vetoketjusta" huolimatta... Emmekö tapa frontendin maailmaa tällä tavalla vielä enemmän?
AG: - Web Assembly on binäärimuoto, ja oletusbinaari ei voi olla suurempi kuin teksti lopullisessa julkaisussa ... Runtime vetää sinut, mutta tämä on sama kuin Javascriptin standardikirjaston hakeminen, kun sitä ei ole, joten käytämme joitain Lodash. En tiedä kuinka kauan Lodash kestää.
in: - Ilmeisesti vähemmän kuin käyttöaika...
AG: - "puhtaalla" Javascriptillä?
in: - Joo. Pakkaamme sen ennen lähettämistä...
AG: - Mutta tämä on tekstiä ... Yleensä megatavu on kuin paljon, mutta siinä kaikki (sinulla on koko suoritusaika). Seuraavaksi kirjoitat oman liiketoimintalogiikkasi, joka kasvattaa binaariasi yhdellä prosentilla. Toistaiseksi en näe sen tappavan etuosaa. Lisäksi Web Assembly toimii nopeammin kuin Javascript selvästä syystä - sitä ei tarvitse jäsentää.
in: - Toistaiseksi kiistanalainen kohta ... "Wasma" (Web Assembly) -täytäntöönpanoa ei vieläkään ole viitettä, jotta voidaan arvioida yksiselitteisesti. Käsitteellisesti kyllä: me kaikki ymmärrämme, että binäärin pitäisi olla nopeampi, mutta saman V8:n nykyinen toteutus on erittäin tehokas.
AG: - Joo.
in: - Kokoonpano siellä toimii todella hienosti, eikä se ole tosiasia, että siitä tulee suurta etua.
AG: - Web Assembly on myös isojen tyyppien tekemiä.
in: - Mielestäni Web Assemblyä on vielä vaikea arvioida toistaiseksi. Useita vuosia on keskusteltu, mutta todellisia saavutuksia on vain vähän.
AG: - Voi olla. Katsotaan.
in: – Meillä ei ole ongelmia taustalla… Ehkä meidän pitäisi jättää nämä ongelmat käyttöliittymään? Miksi mennä sinne?
AG: - Meidän on pidettävä etulinjan henkilökuntaa.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com