Kyiv Go Meetup 2018ko maiatza:
Liderra: - Kaixo guztioi! Eskerrik asko hemen egoteagatik! Gaur bi hizlari ofizial ditugu: Lyosha eta Vanya. Beste bi izango dira denbora nahikoa badugu. Lehenengo hizlaria Alexey Grachev da, GopherJS-en berri emango digu.
Alexey Grachev (aurrerantzean - AG): – Go garatzailea naiz, eta Go-n web zerbitzuak idazten ditut. Batzuetan frontend-ari aurre egin behar zaio, beste batzuetan eskuz sartu behar duzu. Go-ri buruzko nire esperientziaz eta ikerketaz hitz egin nahi dut frontend-ean.
Kondaira hau da: lehenengo Go frontend-ean zergatik exekutatu nahi dugun hitz egingo dugu, gero hau nola egin daitekeen hitz egingo dugu. Bi modu daude: Web Assembly eta GopherJS. Ikus dezagun konponbide horien egoera zein den eta zer egin daitekeen.
Zer gertatzen da frontendarekin?
Denak ados al daude frontendarekin dena ondo dagoela?
Ez al dago proba nahikorik? Eraikitze motela? Ekosistema? Ederki.
Frontend-ari dagokionez, frontend garatzaileetako batek bere liburuan esandako aipua gustatzen zait:
Javascript-ek ez du mota sistemarik. Orain nire lanean zehar aurkitu ditudan arazoei izena emango diet eta nola konpontzen diren azalduko dut.
Mota-sistema orokorrean nekez deitu daiteke mota-sistema Javasript-en - objektu mota adierazten duten lerroak daude, baina, egia esan, honek ez du zerikusirik motekin. Arazo hau TypeScript (Javasript-en gehigarri bat) eta Flow (Javascript-en mota estatikoko egiaztatzailea) konpontzen da. Egia esan, frontend-a Javascript-en tipo txarreko sistema baten arazoa konpontzera iritsi da.
Ez dago liburutegi estandarrik arakatzailean - nabigatzaileetan objektu integratuak eta funtzio "magiko" batzuk daude. Baina Javascript-en ez dago liburutegi estandarrik. Arazo hau jQuery-k behin konpondu zuen jada (denek erabiltzen zuten jQuery funtzionatzeko behar ziren prototipo, laguntzaile eta funtzio guztiekin). Orain denek erabiltzen dute Lodash:
Itzultzeko infernua. Uste dut denek duela 5 bat urte ikusi zutela Javascript kodea, eta dei-itzulketen konplexutasun ikaragarri baten "fideo" bat zirudien. Orain arazo hau konpondu da (ES-15 edo ES-16 kaleratuta), Javascript-en promesak gehitu dira eta denek arnasa errazago hartu dezakete pixka batean.
Promice infernua iritsi zen arte... Ez dakit front-end industriak nola kudeatzen duen, baina beti oihan bitxi batera eramaten dute euren burua. Promesekin infernua egitea ere lortu genuen. Ondoren, arazo hau konpondu genuen primitibo berri bat gehituz - async/wait:
Asinkroniaren arazoa konpondu da. Async/wait hizkuntza ezberdinetan nahiko ezaguna den primitibo bat da. Python-ek eta beste batzuek ikuspegi hau dute - nahiko ona da. Arazoa konponduta.
Zein arazo ez da konpontzen? Esparruen konplexutasuna esponentzialki gero eta handiagoa da, ekosistemaren konplexutasuna eta programen beraiek.
- Javascript sintaxia bitxia da. Denok ezagutzen ditugu array bat eta objektu bat gehitzeko arazoak eta beste txantxa batzuk.
- Javascript paradigma anitzekoa da. Hau bereziki sistema premiagarria da orain ekosistema oso handia denean:
- denek idazten dute estilo ezberdinetan - batzuek egituraz idazten dute, beste batzuek funtzionalki idazten dute, garatzaile ezberdinek modu ezberdinetan idazten dute;
- pakete ezberdinetatik, paradigma desberdinak pakete desberdinak erabiltzen dituzunean;
- Javasript-en programazio funtzionalarekin "dibertsioa" asko dago - rambda liburutegia agertu zen eta orain inork ezin ditu liburutegi honetan idatzitako programak irakurri.
- Horrek guztiak eragin handia du ekosisteman, eta izugarri hazi da. Paketeak bateraezinak dira elkarren artean: batzuk promesetan oinarritzen dira, beste batzuk async/wait-ean oinarritzen dira, beste batzuk callback-etan oinarritzen dira. Paradigma ezberdinetan ere idazten dute!
- Horrek zaila egiten du proiektua mantentzea. Zaila da akats bat aurkitzea kodea irakurri ezin baduzu.
Zer da Web Assembly?
Mozilla Fundazioko eta beste hainbat enpresatako ausartek Web Assembly bezalako gauza bat asmatu zuten. Zer da hau?
- Formatu bitarra onartzen duen arakatzailean eraikitako makina birtual bat da.
- Programa bitarrak bertara iristen dira eta ia modu naturalean exekutatzen dira, hau da, arakatzaileak ez ditu javascript kodearen "fideoak" guztiak analizatu behar aldi bakoitzean.
- Arakatzaile guztiek onartzen dute.
- Hau bytecode denez, edozein hizkuntzatarako konpiladore bat idatz dezakezu.
- Dagoeneko lau arakatzaile nagusiek Web Assembly euskarria dute.
- Laster Go-n jatorrizko laguntza espero dugu. Arkitektura berri hau dagoeneko gehitu da: GOARCH=wasm GOOS=js (laster). Orain arte, nik ulertzen dudanez, ez da funtzionala, baina badago zalantzarik gabe Go-n egongo dela.
Zer egin orain? GopherJS
Web Assembly-rako laguntzarik ez dugun arren, GopherJS bezalako transpiler bat dago.
- Go kodea Javascript "puru" batera transpilatzen da.
- Arakatzaile guztietan exekutatzen da - ez dago arakatzaile modernoek soilik onartzen duten funtzio berririk (hau Vanilla JS da, edozertan exekutatzen dena).
- Go-k duen ia guztiaren laguntza dago, goroutinak eta kanalak barne... hainbeste maite eta ezagutzen dugun guztia.
- Liburutegi estandar ia osoa onartzen da, arakatzailean onartzeak zentzurik ez duten paketeetan izan ezik: syscall, sareko interakzioak (net/http bezero bat dago, baina zerbitzaririk ez, eta bezeroa XMLHttpRequest bidez emulatzen da). Orokorrean, liburutegi estandar osoa dago eskuragarri - hemen nabigatzailean dago, hona hemen Go-ren stdlib, maite duguna.
- Go-n paketeen ekosistema osoa, hirugarrenen soluzio guztiak (txantiloiak, etab.) GopherJS erabiliz konpila daitezke eta arakatzailean exekutatu.
GopherJS oso erraza da eskuratzen - Go pakete arrunt bat besterik ez da. Lortzera joaten gara eta GopherJS komando bat dugu aplikazioa eraikitzeko:
Hau oso txikia da kaixo mundua...
...Go programa arrunt bat, liburutegi fmt pakete estandar arrunt bat eta Binding Js arakatzailearen APIra iristeko. Println kontsolaren erregistro bihurtuko da azkenean eta arakatzaileak "Kaixo gophers" idatziko du! Oso erraza da: GopherJS eraikitzea egiten dugu - arakatzailean abiarazten dugu - dena funtzionatzen du!
Zer daukazu momentu honetan? Loturak
Js esparru ezagun guztietarako loturak daude:
- JQuery;
- Angular.js;
- D3.js big data marrazteko eta lan egiteko;
- React.js;
- VueJS;
- Electron-en laguntza ere badago (hau da, dagoeneko idatzi ditzakegu mahaigaineko aplikazioak Electron-en);
- eta dibertigarriena WebGL da (aplikazio grafiko osoak egin ditzakegu, 3D grafikoak dituzten jokoak barne, musika eta gauza guztiak);
- eta beste hainbat lotura javascript esparru eta liburutegi ezagun guztietarako.
Esparru
- Dagoeneko GopherJS - Vectyrako bereziki garatu den web-esparru bat dago. Hau React.js-en analogo osoa da, baina Go-n bakarrik garatua, GopherJS-en berezitasunekin.
- Jolas-poltsak daude (sorpresa!). Bi ezagunenak aurkitu ditut:
- Engo;
- Ebiten.
Honen itxuraren eta dagoeneko Go-n idatz dezakezunaren adibide pare bat erakutsiko dizkizut:
Edo aukera hau (ezin izan dut 3D jaurtigailurik aurkitu, baina agian badago):
Zer eskaintzen ari naiz?
Orain front-end industria halako egoeran dago, lehen Javascriptetik negar egiten zuten hizkuntza guztiak hara joango direla. Orain dena "Web Asanblada"tan bilduko da. Zer behar dugu hor dagokigun lekua Gopher gisa hartzeko?
Go-k sistemaren programazio-lengoaia dela suposatu du tradizionalki, eta ia ez dago UI-rekin lan egiteko liburutegirik. Bada zerbait, baina erdi abandonatua, erdi ez-funtzionala.
Eta orain aukera ona da GopherJS-en abiaraziko diren Go-n UI liburutegiak egiteko! Azkenean zure markoa idatzi dezakezu! Hau da marko bat idatzi dezakezun unea, eta lehenetariko bat izango da eta adopzio goiztiarra lortuko duzu, eta izar bat izango zara (esparru ona bada).
Dagoeneko Go ekosisteman dauden pakete asko nabigatzailearen berezitasunetara molda ditzakezu (adibidez, Txantiloien motorra). Dagoeneko funtzionatuko dute, lotura erosoak egin ditzakezu, edukia zuzenean arakatzailean erraz errendatu ahal izateko. Gainera, zerbitzarian eta frontend-ean gauza bera eman dezakeen zerbitzu bat egin dezakezu, adibidez, kode bera erabiliz, frontend-eko garatzaileek gustuko duten guztia (orain bakarrik Go-n).
Joko bat idatzi dezakezu! Dibertitzeko bakarrik…
Hori da esan nahi nuen guztia.
Zure galderak
Galdera (aurrerantzean Q deitzen zaio): – Go edo Js idazten dut?
AG: – Errutinak, kanalak, egiturak, txertaketak idazten dituzu – dena Go-n... Ekitaldi batera harpidetzen zara, funtzio bat hor pasatzen duzu.
V: – Beraz, “biluzik” Js idazten dut?
AG: – Ez, Go-n bezala idazten duzu eta arakatzailearen APIra konektatzen zara (APIa ez da aldatu). Zure loturak idatz ditzakezu mezuak kanalera bidaltzeko - ez da zaila.
V: – Zer gertatzen da mugikorra?
AG: – Behin betiko ikusi nuen: Js-ek exekutatzen duen Cordova adabakirako loturak daude. React Native-n - Ez dakit; agian badago, agian ez (ez nintzen bereziki interesatzen). N-go joko-motorrak bi aplikazio mugikor onartzen ditu, bai iOS eta bai Android.
V: – Web Assembly-ri buruzko galdera. Gero eta leku gehiago hartzen ari da, konpresioa eta “zipping” gorabehera... Ez al dugu front-end mundua horrela are gehiago hilko?
AG: – Web Assembly formatu bitarra da, eta bitarra modu lehenetsian ezin da azken bertsioan testua baino gehiago egon... Exekuzio-denbora marraztuta zaude, baina hori ez dagoenean Javascript liburutegi estandarra arrastatzea bezalakoa da, beraz, erabili Lodash batzuk. Ez dakit zenbat hartzen duen Lodashek.
V: - Argi dago exekuzio denbora baino gutxiago...
AG: – Javascript “hutsean”?
V: - Bai. Bidali aurretik konprimitzen dugu...
AG: – Baina hau testua da... Oro har, megabyte bat asko dirudi, baina hori da (exekuzio-denbora osoa duzu). Ondoren, zure negozio-logika idazten duzu, zure bitarra% 1 handituko duena. Orain arte ez dut ikusten hau frontend-a hiltzen. Gainera, Web Assembly-k Javascript baino azkarrago funtzionatuko du argi dagoen arrazoiagatik - ez da analizatu beharrik.
V: – Oraindik puntu polemikoa da... Oraindik ez dago “Vasma”-ren (Web Assembly) erreferentziazko inplementaziorik, anbiguotasunik gabe epaitu ahal izateko. Kontzeptuki, bai: denok ulertzen dugu bitarra azkarragoa izan behar dela, baina egungo V8 beraren inplementazioa oso eraginkorra da.
AG: - Bai.
V: - Bertan konpilazioak oso polita funtzionatzen du eta ez da egia abantaila handirik egongo denik.
AG: – Web Assembly ere mutil handiek egiten dute.
V: – Iruditzen zait oraindik zaila dela Web Assembly epaitzea. Urte asko dira elkarrizketak, baina benetako lorpen gutxi sumatzen dira.
AG: - Agian. Ikusiko dugu.
V: – Ez dugu arazorik backend-ean... Agian arazo hauek frontend-ean utzi beharko genituzke? Zergatik joan hara?
AG: – Lehen lerroko langileen plantilla mantendu behar dugu.
Iragarki batzuk 🙂
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com