Kyiv Go Meetup Mei 2018:
moderator: - Hi almal! Dankie dat jy hier is! Vandag het ons twee amptelike sprekers - Lyosha en Vanya. Daar sal nog twee wees as ons genoeg tyd het. Die eerste spreker is Alexey Grachev, hy sal ons van GopherJS vertel.
Alexey Grachev (hierna – AG): – Ek is 'n Go-ontwikkelaar, en ek skryf webdienste in Go. Soms moet jy die frontend hanteer, soms moet jy met die hand daarin ingaan. Ek wil oor my ervaring en navorsing oor Go op die frontend praat.
Die legende is dit: eers sal ons praat oor hoekom ons Go op die frontend wil laat loop, dan sal ons praat oor hoe dit gedoen kan word. Daar is twee maniere - Web Assembly en GopherJS. Kom ons kyk wat die status van hierdie oplossings is en wat gedoen kan word.
Wat is fout met die frontend?
Stem almal saam dat alles goed is met die frontend?
Is daar nie genoeg toetse nie? Stadige bou? Ekosisteem? Goed.
Wat die frontend betref, hou ek van die aanhaling wat een van die frontend-ontwikkelaars in sy boek gesê het:
Javascript het nie 'n tipe stelsel nie. Nou sal ek die probleme noem wat ek in die loop van my werk ondervind het en verduidelik hoe dit opgelos word.
Die tipe stelsel kan kwalik 'n tipe stelsel in Javasript genoem word - daar is lyne wat die tipe van die voorwerp aandui, maar eintlik het dit niks met tipes te doen nie. Hierdie probleem word opgelos in TypeScript ('n byvoeging tot Javasript) en Flow ('n statiese-tipe kontroleerder in Javascript). Eintlik het die frontend reeds die punt bereik om die probleem van 'n slegte tipe stelsel in Javascript op te los.
Daar is geen standaard biblioteek in die blaaier as sodanig nie - daar is 'n paar ingeboude voorwerpe en "magic" funksies in blaaiers. Maar in Javascript is daar geen standaard biblioteek as sodanig nie. Hierdie probleem is reeds een keer deur jQuery opgelos (almal het jQuery gebruik met al die prototipes, helpers, funksies wat nodig was om te werk). Nou gebruik almal Lodash:
Terugbel hel. Ek dink almal het Javascript-kode ongeveer 5 jaar gelede gesien, en dit het gelyk soos 'n "noedel" van 'n ongelooflike ingewikkeldheid van terugbelopings. Nou is hierdie probleem opgelos (met die vrystelling van ES-15 of ES-16), beloftes is by Javascript gevoeg en almal kan vir 'n rukkie makliker asemhaal.
Totdat die Promice-hel opgedaag het ... Ek weet nie hoe die front-end-industrie dit regkry nie, maar hulle ry hulself altyd in die een of ander vreemde oerwoud in. Ons het ook daarin geslaag om hel op beloftes te maak. Toe het ons hierdie probleem opgelos deur 'n nuwe primitiewe by te voeg - async/wag:
Die probleem met asinchronie is opgelos. Async/await is 'n redelik gewilde primitief in verskeie tale. Python en ander het hierdie benadering - dit is redelik goed. Probleem opgelos.
Watter probleem is nie opgelos nie? Die eksponensieel toenemende kompleksiteit van raamwerke, die kompleksiteit van die ekosisteem en die programme self.
- Javascript-sintaksis is 'n bietjie vreemd. Ons ken almal die probleme met die byvoeging van 'n skikking en 'n voorwerp en ander grappies.
- Javascript is multi-paradigma. Dit is 'n besonder dringende stelsel nou wanneer die ekosisteem baie groot is:
- almal skryf in verskillende style - sommige skryf struktureel, sommige skryf funksioneel, verskillende ontwikkelaars skryf op verskillende maniere;
- uit verskillende pakkette, verskillende paradigmas wanneer jy verskillende pakkette gebruik;
- daar is baie "pret" met funksionele programmering in Javasript - die rambda-biblioteek het verskyn en nou kan niemand programme lees wat in hierdie biblioteek geskryf is nie.
- Dit alles maak 'n groot impak op die ekosisteem, en dit het ongelooflik gegroei. Die pakkette is onversoenbaar met mekaar: sommige is gebaseer op beloftes, sommige is gebaseer op async/wag, sommige is gebaseer op terugbelopings. Hulle skryf ook in verskillende paradigmas!
- Dit maak die projek moeilik om in stand te hou. Dit is moeilik om 'n fout te vind as jy nie die kode kan lees nie.
Wat is websamestelling?
Die dapper ouens van die Mozilla-stigting en 'n aantal ander maatskappye het met so iets soos Web Assembly vorendag gekom. Wat is hierdie?
- Dit is 'n virtuele masjien wat in die blaaier ingebou is wat die binêre formaat ondersteun.
- Binêre programme kom daar en word amper native uitgevoer, dit wil sê, die blaaier hoef nie elke keer al die "noodles" van JavaScript-kode te ontleed nie.
- Alle blaaiers het ondersteuning verklaar.
- Aangesien dit bytecode is, kan jy 'n samesteller vir enige taal skryf.
- Vier groot blaaiers word reeds saam met Web Assembly-ondersteuning gestuur.
- Ons verwag binnekort inheemse ondersteuning in Go. Hierdie nuwe argitektuur is reeds bygevoeg: GOARCH=wasm GOOS=js (binnekort). So ver, soos ek dit verstaan, is dit nie funksioneel nie, maar daar is 'n stelling dat dit beslis in Go sal wees.
Wat om nou te doen? GopherJS
Alhoewel ons nie ondersteuning vir Web Assembly het nie, is daar 'n transpiler soos GopherJS.
- Go-kode word in "suiwer" Javascript getranspileer.
- Werk in alle blaaiers - daar is geen nuwe kenmerke wat slegs deur moderne blaaiers ondersteun word nie (dit is Vanilla JS, wat op enigiets werk).
- Daar is ondersteuning vir byna alles wat Go het, insluitend goroutines en kanale ... alles wat ons so liefhet en weet.
- Byna die hele standaardbiblioteek word ondersteun, behalwe vir daardie pakkette wat dit nie sin maak om in die blaaier te ondersteun nie: syscall, netto interaksies (daar is 'n net/http-kliënt, maar geen bediener nie, en die kliënt word nageboots via XMLHttpRequest). Oor die algemeen is die hele standaardbiblioteek beskikbaar - hier is dit in die blaaier, hier is Go se stdlib, waarvan ons hou.
- Die hele pakket-ekosisteem in Go, alle derdeparty-oplossings (sjabloon, ens.) kan met GopherJS saamgestel word en in die blaaier uitgevoer word.
GopherJS is baie maklik om te kry - dit is net 'n gewone Go-pakket. Ons gaan haal, en ons het 'n GopherJS-opdrag om die toepassing te bou:
Hierdie is so 'n klein hallo wêreld...
... 'n Gereelde Go-program, 'n gewone standaard biblioteek fmt-pakket en Binding Js om die blaaier-API te bereik. Println sal uiteindelik omgeskakel word na konsole log en die blaaier sal "Hallo gophers" skryf! Dit is so eenvoudig: ons bou GopherJS – ons begin dit in die blaaier – alles werk!
Wat het jy op die oomblik? Bindings
Daar is bindings vir alle gewilde js-raamwerke:
- JQuery;
- Angular.js;
- D3.js vir plot en werk met groot data;
- Reageer.js;
- VueJS;
- daar is selfs ondersteuning vir Electron (dit wil sê, ons kan reeds lessenaartoepassings op Electron skryf);
- en die snaaksste ding is WebGL (ons kan volledige grafiese toepassings maak, insluitend speletjies met 3D-grafika, musiek en al die lekkernye);
- en baie ander bindings aan alle gewilde javascript-raamwerke en -biblioteke.
Raamwerk
- Daar is reeds 'n webraamwerk wat spesifiek vir GopherJS - Vecty ontwikkel is. Dit is 'n volwaardige analoog van React.js, maar slegs ontwikkel in Go, met die besonderhede van GopherJS.
- Daar is wildsakke (verrassing!). Ek het die twee gewildste gevind:
- Engo;
- Ebiten.
Ek sal jou 'n paar voorbeelde wys van hoe dit lyk en wat jy reeds in Go kan skryf:
Of hierdie opsie (ek kon nie 'n 3D-skieter vind nie, maar miskien bestaan dit):
Wat bied ek aan?
Nou is die front-end-industrie in so 'n toestand dat al die tale wat voorheen uit Javascript gehuil het, daarheen sal jaag. Nou sal alles saamgestel word in "Web Assemblies". Wat het ons nodig om ons regmatige plek daar as Gophers in te neem?
Go het tradisioneel aanvaar dat dit 'n stelselprogrammeertaal is, en daar is feitlik geen biblioteke om met die UI te werk nie. Daar is iets, maar dit is half verlate, half nie-funksioneel.
En dit is nou 'n goeie kans om UI-biblioteke in Go te maak wat op GopherJS sal loop! Jy kan uiteindelik jou eie raamwerk skryf! Dit is die tyd wanneer jy 'n raamwerk kan skryf, en dit sal een van die eerstes wees en vroeë aanneming kry, en jy sal 'n ster wees (as dit 'n goeie raamwerk is).
Jy kan baie verskillende pakkette wat reeds in die Go-ekosisteem is, aanpas by die besonderhede van die blaaier (byvoorbeeld, Template-enjin). Hulle sal reeds werk, jy kan gerieflike bindings maak sodat jy die inhoud maklik direk in die blaaier kan weergee. Boonop kan u byvoorbeeld 'n diens maak wat dieselfde ding op die bediener en aan die voorkant kan lewer, met dieselfde kode - alles waarvan front-end ontwikkelaars hou (net nou in Go).
Jy kan 'n speletjie skryf! Net vir die pret…
Dis al wat ek wou sê.
vrae
Vraag (hierna verwys as Q): – Skryf ek in Go of Js?
AG: – Jy skryf roetines, kanale, strukture, inbedding – alles in Go... Jy teken in op 'n geleentheid, slaag 'n funksie daar.
IN: – So ek skryf in “naakte” Js?
AG: – Nee, jy skryf asof in Go en koppel aan die blaaier-API (die API het nie verander nie). Jy kan jou eie bindings skryf sodat boodskappe na die kanaal gestuur word - dit is nie moeilik nie.
IN: – Wat van selfoon?
AG: – Ek het beslis gesien: daar is bindings vir die Cordova-pleister wat Js laat loop. In React Native - ek weet nie; miskien is daar, miskien nie (ek het nie besonder belanggestel nie). Die N-go-speletjie-enjin ondersteun beide mobiele toepassings – beide iOS en Android.
IN: – Vraag oor websamestelling. Al hoe meer spasie word in beslag geneem, ten spyte van die compressie en “zipping”... Sal ons nie die front-end wêreld op hierdie manier nog meer doodmaak nie?
AG: – Web Assembly is 'n binêre formaat, en binêr kan by verstek nie meer as teks in die finale vrystelling wees nie... Jy word na looptyd getrek, maar dit is dieselfde as om die standaard Javascript-biblioteek uit te sleep wanneer dit nie daar is nie, so ons gebruik 'n bietjie Lodash. Ek weet nie hoeveel Lodash vat nie.
IN: - Duidelik minder as looptyd ...
AG: – In “suiwer” Javascript?
IN: - Ja. Ons druk dit saam voordat ons dit stuur ...
AG: – Maar dit is teks ... Oor die algemeen lyk 'n megagreep na baie, maar dit is al (jy het die hele looptyd). Vervolgens skryf jy jou eie besigheidslogika, wat jou binêre met 1% sal verhoog. Tot dusver sien ek nie dat dit die frontend doodmaak nie. Boonop sal Web Assembly vinniger werk as Javascript vir die ooglopende rede - dit hoef nie ontleed te word nie.
IN: – Dit is steeds ’n omstrede punt... Daar is nog nie enige verwysingsimplementering van “Vasma” (Web Assembly) sodat ’n mens ondubbelsinnig kan oordeel nie. Konseptueel, ja: ons verstaan almal dat binêre vinniger moet wees, maar die huidige implementering van dieselfde V8 is baie doeltreffend.
AG: - Ja.
IN: – Samestelling daar werk regtig baie gaaf en dit is nie 'n feit dat daar 'n groot voordeel sal wees nie.
AG: – Web Assembly word ook deur groot ouens gemaak.
IN: – Dit lyk vir my of dit steeds moeilik is om Web Assembly te beoordeel. Daar is nou al baie jare gesprekke, maar daar is min werklike prestasies wat gevoel kan word.
AG: - Kan wees. Ons sal sien.
IN: - Ons het nie probleme op die agterkant nie ... Miskien moet ons hierdie probleme op die voorkant laat? Hoekom soontoe gaan?
AG: – Ons moet 'n personeel van frontlinie-werkers aanhou.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com