Kyiv Go Meetup mei 2018:
Lead: - Hoi allegearre! Tank foar it wêzen hjir! Hjoed hawwe wy twa offisjele sprekkers - Lyosha en Vanya. Der komme noch twa as wy genôch tiid hawwe. De earste sprekker is Alexey Grachev, hy sil ús fertelle oer GopherJS.
Alexey Grachev (hjirnei - AG): - Ik bin in Go-ûntwikkelder, en ik skriuw webtsjinsten yn Go. Soms moatte jo mei de frontend omgean, soms moatte jo der mei de hân yn komme. Ik wol prate oer myn ûnderfining en ûndersyk nei Go on the frontend.
De leginde is dit: earst sille wy prate oer wêrom't wy Go op 'e frontend wolle útfiere, dan sille wy prate oer hoe't dit kin wurde dien. D'r binne twa manieren - Web Assembly en GopherJS. Litte wy sjen wat de status fan dizze oplossingen is en wat kin wurde dien.
Wat is der mis mei de frontend?
Is elkenien it iens dat alles goed is mei de frontend?
Binne der net genôch tests? Stadich bouwen? Ekosysteem? Moai.
Oangeande de frontend hâld ik fan it sitaat dat ien fan 'e frontend-ûntwikkelders sei yn syn boek:
Javascript hat gjin type systeem. No sil ik de problemen neame dy't ik yn 'e rin fan myn wurk tsjinkaam en útlizze hoe't se wurde oplost.
It typesysteem yn it algemien kin amper in typesysteem neamd wurde yn Javasript - d'r binne rigels dy't it type fan it objekt oanjaan, mar feitlik hat dit neat te krijen mei typen. Dit probleem wurdt oplost yn TypeScript (in tafoeging oan Javasript) en Flow (in statyske type checker yn Javascript). Eins hat de frontend al it punt berikt om it probleem fan in min type systeem yn Javascript op te lossen.
D'r is gjin standertbibleteek yn 'e browser as sadanich - d'r binne wat ynboude objekten en "magyske" funksjes yn browsers. Mar yn Javascript is d'r gjin standertbibleteek as sadanich. Dit probleem waard al ien kear oplost troch jQuery (elkenien brûkte jQuery mei alle prototypen, helpers, funksjes dy't nedich wiene om te wurkjen). No brûkt elkenien Lodash:
Callback hel. Ik tink dat elkenien Javascript-koade sawat 5 jier lyn seach, en it like in "noodle" fan in ongelooflijke yngewikkeldheid fan callbacks. No is dit probleem oplost (mei de frijlitting fan ES-15 of ES-16), beloften binne tafoege oan Javascript en elkenien kin in skoftke makliker sykhelje.
Oant Promice hel kaam ... Ik wit net hoe't de front-end yndustry beheart, mar se altyd ride harsels yn guon frjemde jungle. Wy hawwe ek slagge om hel op beloften. Dan hawwe wy dit probleem oplost troch in nije primitive ta te foegjen - async/await:
It probleem mei asynchrony is oplost. Async/await is in frij populêr primityf yn ferskate talen. Python en oaren hawwe dizze oanpak - it is frij goed. Probleem oplost.
Hokker probleem is net oplost? De eksponinsjele tanimmende kompleksiteit fan kaders, de kompleksiteit fan it ekosysteem en de programma's sels.
- Javascript syntaksis is in bytsje nuver. Wy witte allegear de problemen mei it tafoegjen fan in array en in objekt en oare grappen.
- Javascript is multi-paradigma. Dit is in bysûnder driuwend systeem no as it ekosysteem heul grut is:
- elkenien skriuwt yn ferskillende stilen - guon skriuwe struktureel, guon skriuwe funksjoneel, ferskate ûntwikkelders skriuwe op ferskate manieren;
- fan ferskate pakketten, ferskillende paradigma's as jo ferskate pakketten brûke;
- d'r is in protte "leuk" mei funksjonele programmearring yn Javasript - de rambda-bibleteek ferskynde en no kin gjinien programma's lêze skreaun yn dizze bibleteek.
- Dit alles makket in grutte ynfloed op it ekosysteem, en it is ongelooflijk groeid. De pakketten binne net kompatibel mei elkoar: guon binne basearre op beloften, guon binne basearre op async / wachtsje, guon binne basearre op callbacks. Se skriuwe ek yn ferskate paradigma's!
- Dit makket it projekt dreech te ûnderhâlden. It is dreech om in brek te finen as jo de koade net lêze kinne.
Wat is Web Assembly?
De dappere jonges fan de Mozilla Foundation en in oantal oare bedriuwen kamen mei sa'n ding as Web Assembly. Wat is dit?
- Dit is in firtuele masine ynboud yn 'e browser dy't it binêre formaat stipet.
- Binêre programma's komme dêr en wurde hast native útfierd, dat is, de browser hoecht net elke kear alle "noodles" fan javascript-koade te parsearjen.
- Alle browsers hawwe stipe ferklearre.
- Om't dit bytekoade is, kinne jo in kompilator foar elke taal skriuwe.
- Fjouwer grutte browsers binne al ferstjoerd mei Web Assembly-stipe.
- Wy ferwachtsje native stipe yn Go gau. Dizze nije arsjitektuer is al tafoege: GOARCH=wasm GOOS=js (gau). Sa fier, sa't ik begryp it, it is net funksjoneel, mar der is in ferklearring dat it sil grif wêze yn Go.
Wat no te dwaan? GopherJS
Wylst wy gjin stipe hawwe foar Web Assembly, is d'r in transpiler lykas GopherJS.
- Go-koade wurdt transpilearre yn "suver" Javascript.
- Rint yn alle browsers - d'r binne gjin nije funksjes dy't allinich wurde stipe troch moderne browsers (dit is Vanilla JS, dy't op alles rint).
- D'r is stipe foar hast alles wat Go hat, ynklusyf goroutines en kanalen ... alles wat wy sa leaf ha en witte.
- Hast de hiele standert bibleteek wurdt stipe, útsein foar dy pakketten dat it makket gjin sin te stypjen yn 'e blêder: syscall, net ynteraksjes (der is in net / http client, mar gjin tsjinner, en de client wurdt emulearre fia XMLHttpRequest). Yn 't algemien is de heule standertbibleteek beskikber - hjir is it yn' e browser, hjir is Go's stdlib, dy't wy hâlde.
- It hiele pakket-ekosysteem yn Go, alle oplossingen fan tredden (templating, ensfh.) kinne wurde kompilearre mei GopherJS en rinne yn 'e browser.
GopherJS is heul maklik te krijen - it is gewoan in gewoan Go-pakket. Wy geane krije, en wy hawwe in GopherJS-kommando om de applikaasje te bouwen:
Dit is sa'n lytse hallo wrâld ...
...In gewoan Go-programma, in gewoan standert bibleteek fmt-pakket en Binding Js om de browser API te berikken. Println sil úteinlik wurde omboud ta konsole-log en de browser sil "Hallo gophers" skriuwe! It is sa ienfâldich: wy bouwe GopherJS - wy lansearje it yn 'e browser - alles wurket!
Wat hawwe jo op it stuit? Binings
D'r binne bindingen foar alle populêre js-frames:
- JQuery;
- Angular.js;
- D3.js foar it plotjen en wurkjen mei grutte gegevens;
- React.js;
- VueJS;
- d'r is sels stipe foar Electron (dat is, wy kinne al buroblêdapplikaasjes op Electron skriuwe);
- en it grappichste ding is WebGL (wy kinne folsleine grafyske applikaasjes meitsje, ynklusyf spultsjes mei 3D-grafiken, muzyk en al it guod);
- en in protte oare bindingen oan alle populêre javascript-kaders en bibleteken.
Framework
- D'r is in webkader al spesifyk ûntwikkele foar GopherJS - Vecty. Dit is in folweardige analoog fan React.js, mar allinich ûntwikkele yn Go, mei de spesifikaasjes fan GopherJS.
- Der binne spultsje bags (ferrassing!). Ik fûn de twa populêrste:
- engo;
- Ebiten.
Ik sil jo in pear foarbylden sjen litte fan hoe't it derút sjocht en wat jo al kinne skriuwe yn Go:
Of dizze opsje (ik koe gjin 3D-shooter fine, mar miskien bestiet it):
Wat bied ik oan?
No is de front-end-yndustry yn sa'n steat dat alle talen dy't earder rôpen fan Javascript derhinne sille. No sil alles wurde gearstald yn "Web Assemblies". Wat hawwe wy nedich om ús rjochtmjittige plak dêr as Gophers yn te nimmen?
Go hat tradisjoneel oannommen dat it in systeemprogrammearringstaal is, en d'r binne praktysk gjin biblioteken foar wurkjen mei de UI. Der is wat, mar it is heal ferlitten, heal net-funksjoneel.
En no is in goede kâns om UI-biblioteken te meitsjen yn Go dy't sille rinne op GopherJS! Jo kinne einlings jo eigen ramt skriuwe! Dit is de tiid as jo kinne skriuwe in ramt, en it sil wêze ien fan de earste en fa betiid fêststelling, en do silst wêze in stjer (as it is in goed ramt).
Jo kinne in protte ferskillende pakketten oanpasse dy't al yn it Go-ekosysteem binne oan 'e spesifikaasjes fan' e browser (bygelyks Template-motor). Se sille al wurkje, jo kinne handige bindingen meitsje, sadat jo de ynhâld maklik direkt yn 'e browser kinne werjaan. Plus, jo kinne bygelyks in tsjinst meitsje dy't itselde ding kin leverje op 'e server en op' e front-end, mei deselde koade - alles wat front-end-ûntwikkelders leuk fine (allinnich no yn Go).
Jo kinne in spultsje skriuwe! Gewoan foar de aardichheid...
Dat woe ik net sizze.
Jo fragen
Fraach (hjirnei oantsjutten as Q): – Skriuw ik yn Go of Js?
AG: – Jo skriuwe routines, kanalen, struktueren, ynbêding – alles yn Go... Jo abonnearje op in evenemint, jouwe dêr in funksje troch.
Yn: - Dus ik skriuw yn "neaken" Js?
AG: - Nee, jo skriuwe as yn Go en ferbine mei de browser API (de API is net feroare). Jo kinne jo eigen bindingen skriuwe, sadat berjochten nei it kanaal stjoerd wurde - it is net dreech.
Yn: - Hoe sit it mei mobyl?
AG: – Ik seach definityf: der binne binings foar de Cordova patch dy't Js rint. In React Native - ik wit it net; miskien is der, miskien net (Ik wie net bysûnder ynteressearre). De N-go-spielmotor stipet beide mobile applikaasjes - sawol iOS as Android.
Yn: - Fraach oer Web Assembly. Hieltyd mear romte wurdt ynnommen, nettsjinsteande de kompresje en "zippen" ... Sille wy de front-end wrâld op dizze manier net noch mear deadzje?
AG: – Web Assembly is in binêr formaat, en binêr kin standert net yn 'e definitive release mear wêze as tekst ... Jo wurde lutsen nei runtime, mar dit is itselde as it slepen fan 'e standert Javascript-bibleteek as it der net is, dus wy brûk wat Lodash. Ik wit net hoefolle Lodash nimt.
Yn: - Fansels minder dan runtime ...
AG: - Yn "suver" Javascript?
Yn: - Ja. Wy komprimearje it foardat jo it ferstjoere ...
AG: - Mar dit is tekst ... Yn 't algemien liket in megabyte in protte, mar dat is alles (jo hawwe de hiele runtime). Dêrnei skriuwe jo jo eigen bedriuwslogika, dy't jo binêre mei 1% ferheegje sil. Oant no sjoch ik net dat dit de frontend deadzje. Boppedat sil Web Assembly rapper wurkje dan Javascript foar de foar de hân lizzende reden - it hoecht net te parseard.
Yn: - Dit is noch altyd in kontroversjeel punt ... Der is noch gjin referinsje ymplemintaasje fan "Vasma" (Web Assembly) sadat men kin oardielje ûndûbelsinnich. Konseptueel, ja: wy begripe allegear dat binêr flugger moat wêze, mar de hjoeddeistige ymplemintaasje fan deselde V8 is heul effisjint.
AG: - Ja.
Yn: - Kompilaasje dêr wurket echt hiel cool en it is net in feit dat der sil wêze in grut foardiel.
AG: - Web Assembly wurdt ek makke troch grutte jonges.
Yn: - It liket my ta dat it noch dreech is om Web Assembly te oardieljen. D'r binne al in protte jierren petearen, mar d'r binne in pear echte prestaasjes dy't fiele kinne.
AG: - Miskien. Wy sille sjen.
Yn: - Wy hawwe gjin problemen op 'e efterkant ... Miskien moatte wy dizze problemen op' e frontend litte? Wêrom gean dêr?
AG: - Wy moatte in personiel fan frontline-arbeiders hâlde.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com