Kyiv Go Meetup Mayo 2018:
Humantong: - Kamusta kayong lahat! Maraming salamat at narito ka! Ngayon mayroon kaming dalawang opisyal na tagapagsalita - sina Lyosha at Vanya. Dalawa pa kung may sapat na oras. Ang unang tagapagsalita ay si Alexey Grachev, sasabihin niya sa amin ang tungkol sa GopherJS.
Alexey Grachev (pagkatapos nito - AG): – Ako ay isang developer ng Go, at nagsusulat ako ng mga serbisyo sa web sa Go. Minsan kailangan mong harapin ang frontend, minsan kailangan mong pasukin ito nang manu-mano. Gusto kong pag-usapan ang aking karanasan at pagsasaliksik sa Go sa frontend.
Ang alamat ay ito: pag-uusapan muna natin kung bakit gusto nating tumakbo sa Go sa frontend, pagkatapos ay pag-uusapan natin kung paano ito magagawa. Mayroong dalawang paraan - Web Assembly at GopherJS. Tingnan natin kung ano ang katayuan ng mga solusyong ito at kung ano ang maaaring gawin.
Ano ang mali sa frontend?
Sumasang-ayon ba ang lahat na maayos ang lahat sa frontend?
Hindi ba sapat ang mga pagsubok? Mabagal na pagbuo? Ecosystem? ayos lang.
Tungkol sa frontend, gusto ko ang quote na sinabi ng isa sa mga developer ng frontend sa kanyang aklat:
Walang uri ng system ang Javascript. Ngayon ay pangalanan ko ang mga problema na naranasan ko sa kurso ng aking trabaho at ipaliwanag kung paano ito nalutas.
Ang uri ng sistema sa pangkalahatan ay halos hindi matatawag na isang uri ng sistema sa Javasript - may mga linya na nagpapahiwatig ng uri ng bagay, ngunit sa katunayan ito ay walang kinalaman sa mga uri. Ang problemang ito ay nalutas sa TypeScript (isang add-on sa Javasript) at Flow (isang static-type checker sa Javascript). Sa totoo lang, ang frontend ay umabot na sa punto ng paglutas ng problema ng isang masamang uri ng sistema sa Javascript.
Walang karaniwang library sa browser tulad nito - mayroong ilang mga built-in na bagay at "magic" function sa mga browser. Ngunit sa Javascript walang karaniwang aklatan tulad nito. Ang problemang ito ay nalutas nang isang beses sa pamamagitan ng jQuery (lahat ay gumamit ng jQuery kasama ang lahat ng mga prototype, katulong, mga function na kinakailangan upang gumana). Ngayon lahat ay gumagamit ng Lodash:
Callback hell. Sa tingin ko lahat ay nakakita ng Javascript code mga 5 taon na ang nakakaraan, at ito ay mukhang isang "noodle" ng isang hindi kapani-paniwalang pagkasalimuot ng mga callback. Ngayon ang problemang ito ay nalutas na (kasama ang paglabas ng ES-15 o ES-16), ang mga pangako ay idinagdag sa Javascript at lahat ay makakahinga nang mas madali sa ilang sandali.
Hanggang sa dumating ang Promice hell... Hindi ko alam kung paano namamahala ang front-end na industriya, ngunit palagi silang nagtutulak sa kanilang sarili sa ilang kakaibang gubat. Nagawa din naming gumawa ng impiyerno sa mga pangako. Pagkatapos ay nalutas namin ang problemang ito sa pamamagitan ng pagdaragdag ng bagong primitive - async/wait:
Ang problema sa asynchrony ay nalutas. Ang Async/wait ay isang medyo sikat na primitive sa iba't ibang wika. Ang Python at iba pa ay may ganitong diskarte - ito ay medyo mahusay. Nalutas ang problema.
Anong problema ang hindi nalutas? Ang mabilis na pagtaas ng pagiging kumplikado ng mga frameworks, ang pagiging kumplikado ng ecosystem at ang mga programa mismo.
- Ang syntax ng Javascript ay medyo kakaiba. Alam nating lahat ang mga problema sa pagdaragdag ng isang array at isang bagay at iba pang mga biro.
- Ang Javascript ay multi-paradigm. Ito ay isang partikular na pagpindot na sistema ngayon kapag ang ecosystem ay napakalaki:
- lahat ay nagsusulat sa iba't ibang mga estilo - ang ilan ay sumulat sa istruktura, ang ilan ay sumusulat sa pagganap, ang iba't ibang mga developer ay nagsusulat sa iba't ibang paraan;
- mula sa iba't ibang mga pakete, iba't ibang paradigms kapag gumamit ka ng iba't ibang mga pakete;
- mayroong maraming "masaya" sa functional programming sa Javasript - lumitaw ang rambda library at ngayon ay walang makakabasa ng mga program na nakasulat sa library na ito.
- Ang lahat ng ito ay may malaking epekto sa ecosystem, at ito ay lumago nang hindi kapani-paniwala. Ang mga pakete ay hindi tugma sa isa't isa: ang ilan ay batay sa mga pangako, ang ilan ay batay sa async/paghihintay, ang ilan ay batay sa mga callback. Sumulat din sila sa iba't ibang paradigma!
- Ginagawa nitong mahirap mapanatili ang proyekto. Mahirap maghanap ng bug kung hindi mo mabasa ang code.
Ano ang Web Assembly?
Ang mga magigiting na lalaki mula sa Mozilla Foundation at maraming iba pang mga kumpanya ay nakaisip ng isang bagay tulad ng Web Assembly. Ano ito?
- Ito ay isang virtual machine na binuo sa browser na sumusuporta sa binary na format.
- Nakarating doon ang mga binary program at halos native na isinasagawa, iyon ay, hindi kailangang i-parse ng browser ang lahat ng "noodles" ng javascript code sa bawat oras.
- Ang lahat ng mga browser ay nagpahayag ng suporta.
- Dahil ito ay bytecode, maaari kang magsulat ng isang compiler para sa anumang wika.
- Apat na pangunahing browser ang nagpapadala na ng suporta sa Web Assembly.
- Inaasahan namin ang katutubong suporta sa Go sa lalong madaling panahon. Ang bagong arkitektura na ito ay naidagdag na: GOARCH=wasm GOOS=js (soon). Sa ngayon, sa pagkakaintindi ko, hindi ito functional, ngunit may pahayag na tiyak na ito ay nasa Go.
Ano ang dapat gawin ngayon? GopherJS
Bagama't wala kaming suporta para sa Web Assembly, mayroong isang transpiler tulad ng GopherJS.
- Ang go code ay inilipat sa "purong" Javascript.
- Gumagana sa lahat ng mga browser - walang mga bagong tampok na sinusuportahan lamang ng mga modernong browser (ito ay Vanilla JS, na tumatakbo sa anumang bagay).
- Mayroong suporta para sa halos lahat ng mayroon si Go, kabilang ang mga goroutine at channel... lahat ng bagay na mahal at alam namin nang labis.
- Halos ang buong karaniwang library ay suportado, maliban sa mga paketeng iyon na walang saysay na suportahan sa browser: syscall, mga pakikipag-ugnayan sa net (mayroong net/http client, ngunit walang server, at ang kliyente ay ginagaya sa pamamagitan ng XMLHttpRequest). Sa pangkalahatan, available ang buong karaniwang library - narito ito sa browser, narito ang stdlib ni Go, na gusto namin.
- Ang buong package ecosystem sa Go, lahat ng third-party na solusyon (templating, atbp.) ay maaaring i-compile gamit ang GopherJS at tumakbo sa browser.
Napakadaling makuha ang GopherJS - isa lang itong regular na package ng Go. Kukuha na kami, at mayroon kaming GopherJS command para buuin ang application:
Ito ay napakaliit na hello world...
...Isang regular na Go program, isang regular na karaniwang library fmt package at Binding Js para maabot ang browser API. Sa kalaunan ay mako-convert ang Println sa console log at isusulat ng browser ang "Hello gophers"! Ganun lang kasimple: gumagawa kami ng GopherJS build – inilunsad namin ito sa browser – gumagana ang lahat!
Ano ang mayroon ka sa ngayon? Mga binding
Mayroong mga binding para sa lahat ng sikat na js frameworks:
- JQuery;
- Angular.js;
- D3.js para sa pag-plot at pagtatrabaho sa malaking data;
- React.js;
- VueJS;
- mayroon ding suporta para sa Electron (iyon ay, maaari na tayong sumulat ng mga desktop application sa Electron);
- at ang pinakanakakatawang bagay ay ang WebGL (maaari tayong gumawa ng mga full-graphic na application, kabilang ang mga laro na may 3D graphics, musika at lahat ng mga goodies);
- at marami pang ibang binding sa lahat ng sikat na javascript frameworks at library.
Balangkas
- Mayroong isang web framework na partikular na binuo para sa GopherJS - Vecty. Isa itong ganap na analogue ng React.js, ngunit binuo lamang sa Go, na may mga detalye ng GopherJS.
- May mga game bags (sorpresa!). Natagpuan ko ang dalawang pinakasikat:
- Engo;
- Ebiten.
Magpapakita ako sa iyo ng ilang halimbawa kung ano ang hitsura nito at kung ano ang maaari mo nang isulat sa Go:
O ang pagpipiliang ito (hindi ako makahanap ng isang 3D shooter, ngunit marahil ito ay umiiral):
Ano ang iniaalok ko?
Ngayon ang front-end na industriya ay nasa isang estado na ang lahat ng mga wika na dati ay sumigaw mula sa Javascript ay dadaloy doon. Ngayon ang lahat ay isasama sa "Web Assemblies". Ano ang kailangan nating kunin ang ating nararapat na lugar doon bilang Gophers?
Tradisyonal na ipinapalagay ni Go na ito ay isang System programming language, at halos walang mga aklatan para sa pagtatrabaho sa UI. Mayroong isang bagay, ngunit ito ay kalahating inabandona, kalahati ay hindi gumagana.
At ngayon ay isang magandang pagkakataon na gumawa ng mga library ng UI sa Go na tatakbo sa GopherJS! Sa wakas ay makakasulat ka na ng iyong sariling balangkas! Ito ang oras kung kailan maaari kang magsulat ng isang balangkas, at ito ay magiging isa sa mga una at makakuha ng maagang pag-aampon, at ikaw ay magiging isang bituin (kung ito ay isang mahusay na balangkas).
Maaari mong iakma ang maraming iba't ibang mga pakete na nasa Go ecosystem na sa mga detalye ng browser (halimbawa, Template engine). Gumagana na ang mga ito, maaari kang gumawa ng maginhawang mga binding upang madali mong mai-render ang nilalaman nang direkta sa browser. Dagdag pa, maaari kang gumawa, halimbawa, ng isang serbisyo na maaaring mag-render ng parehong bagay sa server at sa front-end, gamit ang parehong code - lahat ng gusto ng mga front-end na developer (ngayon lang sa Go).
Maaari kang magsulat ng isang laro! Katuwaan lang...
Yun lang ang gusto kong sabihin.
mga katanungan
Tanong (mula rito ay tinutukoy bilang Q): – Nagsusulat ba ako sa Go o Js?
AG: – Sumulat ka ng mga gawain, channel, istruktura, pag-embed – lahat ng bagay sa Go... Nag-subscribe ka sa isang kaganapan, nagpasa ng isang function doon.
SA: – Kaya nagsusulat ako sa "hubad" na Js?
AG: – Hindi, sumulat ka na parang nasa Go at kumonekta sa browser API (hindi nagbago ang API). Maaari kang magsulat ng sarili mong mga binding upang maipadala ang mga mensahe sa channel - hindi ito mahirap.
SA: – Paano ang tungkol sa mobile?
AG: – Talagang nakita ko: may mga binding para sa patch ng Cordova na pinapatakbo ni Js. Sa React Native - Hindi ko alam; baka meron, baka wala (I wasn’t particular interested). Ang N-go game engine ay sumusuporta sa parehong mga mobile application - parehong iOS at Android.
SA: – Tanong tungkol sa Web Assembly. Parami nang parami ang puwang na kinukuha, sa kabila ng compression at "zipping"... Hindi ba natin mas papatayin ang front-end na mundo sa ganitong paraan?
AG: – Ang Web Assembly ay isang binary na format, at ang binary bilang default ay hindi maaaring nasa huling release nang higit pa sa text... Naaakit ka sa runtime, ngunit ito ay kapareho ng pag-drag palabas ng karaniwang Javascript library kapag wala ito, kaya kami gumamit ng ilang Lodash. Hindi ko alam kung magkano ang kinukuha ni Lodash.
SA: – Malinaw na mas mababa kaysa sa runtime...
AG: - Sa "purong" Javascript?
SA: - Oo. I-compress namin ito bago ipadala...
AG: – Ngunit ito ay teksto... Sa pangkalahatan, ang isang megabyte ay parang marami, ngunit iyon lang (mayroon kang buong runtime). Susunod, isusulat mo ang iyong sariling lohika ng negosyo, na magpapataas ng iyong binary ng 1%. Sa ngayon ay hindi ko pa nakikitang pumapatay ito sa frontend. Bukod dito, gagana ang Web Assembly nang mas mabilis kaysa sa Javascript para sa malinaw na dahilan - hindi ito kailangang ma-parse.
SA: – Ito ay isang kontrobersyal na punto pa rin... Wala pang anumang reference na pagpapatupad ng “Vasma” (Web Assembly) upang ang isa ay makapaghusga nang hindi malabo. Sa konsepto, oo: naiintindihan nating lahat na ang binary ay dapat na mas mabilis, ngunit ang kasalukuyang pagpapatupad ng parehong V8 ay napakahusay.
AG: - Oo.
SA: – Gumagana talaga ang compilation doon at hindi isang katotohanan na magkakaroon ng malaking kalamangan.
AG: – Ang Web Assembly ay ginawa din ng malalaking tao.
SA: – Para sa akin ay mahirap pa ring husgahan ang Web Assembly. Maraming mga taon na ang napag-usapan, ngunit kakaunti ang mga tunay na tagumpay na mararamdaman.
AG: - Siguro. Makikita natin.
SA: – Wala kaming mga problema sa backend... Siguro dapat naming iwanan ang mga problemang ito sa frontend? Bakit pumunta doon?
AG: – Kailangan nating panatilihin ang isang tauhan ng mga manggagawa sa harap.
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com