Kyiv Go Meetup 2018 оны XNUMX-р сар:
Удирдах ажил: - Сайн уу! Энд байгаад баярлалаа! Өнөөдөр бид хоёр албан ёсны илтгэгчтэй - Лёша, Ваня. Хэрэв бидэнд хангалттай хугацаа байвал дахиад хоёр байх болно. Эхний илтгэгч бол Алексей Грачев, тэр бидэнд GopherJS-ийн талаар ярих болно.
Алексей Грачев (цаашид - AG): – Би Go хөгжүүлэгч бөгөөд Go дээр вэб үйлчилгээ бичдэг. Заримдаа та урд талдаа ажиллах хэрэгтэй болдог, заримдаа та үүнийг гараар оруулах хэрэгтэй болдог. Би Go on frontend дээр хийсэн туршлага, судалгааныхаа талаар ярихыг хүсч байна.
Домог бол: эхлээд бид яагаад Go програмыг урд талдаа ажиллуулахыг хүсч байгаагаа, дараа нь үүнийг хэрхэн хийх талаар ярилцах болно. Web Assembly болон GopherJS гэсэн хоёр арга бий. Эдгээр шийдлүүдийн төлөв байдал, юу хийж болохыг харцгаая.
Урд талд нь юу нь болохгүй байна вэ?
Бүх зүйл урд талдаа сайн байгаа гэдэгтэй хүн бүр санал нийлэх үү?
Тест хангалтгүй байна уу? Удаан барих уу? Экосистем? Сайн байна.
Frontend-ийн тухайд, урд талын хөгжүүлэгчдийн нэг номондоо хэлсэн эшлэл надад таалагдаж байна:
Javascript нь төрлийн системгүй. Одоо би ажлын явцад тулгарч байсан асуудлуудыг нэрлэж, тэдгээрийг хэрхэн шийдвэрлэж байгааг тайлбарлах болно.
Ер нь төрлийн системийг Javasript-д төрлийн систем гэж нэрлэх нь хэцүү байдаг - объектын төрлийг харуулсан мөрүүд байдаг боловч үнэндээ энэ нь төрлүүдтэй ямар ч холбоогүй юм. Энэ асуудлыг TypeScript (Javasript-ийн нэмэлт) болон Flow (Javascript дахь статик төрлийн шалгагч) дээр шийддэг. Үнэн хэрэгтээ, frontend нь Javascript дахь муу төрлийн системийн асуудлыг шийдэх цэгт аль хэдийн хүрсэн байна.
Хөтөч дээр стандарт номын сан байдаггүй - хөтчүүдэд суулгасан объектууд болон "шидэт" функцүүд байдаг. Гэхдээ Javascript дээр ийм стандарт номын сан байдаггүй. Энэ асуудлыг jQuery аль хэдийн нэг удаа шийдэж байсан (хүн бүр jQuery-г ажиллахад шаардлагатай бүх прототип, туслагч, функцтэй ашигладаг байсан). Одоо хүн бүр Lodash-г ашигладаг:
Буцах там. 5 жилийн өмнө хүн бүр Javascript кодыг харсан бөгөөд энэ нь дахин дуудлагын гайхалтай нарийн төвөгтэй "гоймон" шиг харагдаж байсан гэж би бодож байна. Одоо энэ асуудал шийдэгдсэн (ES-15 эсвэл ES-16-г гаргаснаар), Javascript дээр амлалтууд нэмэгдсэн бөгөөд хүн бүр хэсэг хугацаанд илүү хялбар амьсгалж чадна.
Промисын там ирэх хүртэл... Урд талын салбар хэрхэн удирддагийг би мэдэхгүй ч тэд үргэлж хачин ширэнгэн ой руу явдаг. Бид ч амлалтаараа там хийж чадлаа. Дараа нь бид шинэ командыг нэмж энэ асуудлыг шийдсэн - async/await:
Асинхронтой холбоотой асуудал шийдэгдсэн. Async/await нь янз бүрийн хэл дээрх нэлээд түгээмэл команд юм. Python болон бусад хүмүүст ийм хандлага байдаг - энэ нь маш сайн. Асуудал шийдэгдэж.
Ямар асуудал шийдэгдээгүй байна вэ? Хүрээний экспоненциал өсөн нэмэгдэж буй нарийн төвөгтэй байдал, экосистемийн нарийн төвөгтэй байдал, хөтөлбөрүүд өөрсдөө.
- Javascript синтакс нь жаахан хачин юм. Массив, объект нэмэхтэй холбоотой асуудлууд болон бусад хошигнолуудыг бид бүгд мэднэ.
- Javascript бол олон парадигм юм. Энэ нь экосистем маш том болсон үед онцгой тулгамдсан систем юм:
- хүн бүр өөр өөр хэв маягаар бичдэг - зарим нь бүтцийн хувьд бичдэг, зарим нь функциональ байдлаар бичдэг, өөр өөр хөгжүүлэгчид өөр өөр хэлбэрээр бичдэг;
- өөр багцуудыг ашиглах үед өөр өөр багц, өөр өөр парадигмуудаас;
- Javasript дээр функциональ програмчлалын хувьд маш их "хөгжилтэй" байдаг - рамбда номын сан гарч ирсэн бөгөөд одоо хэн ч энэ номын санд бичигдсэн програмуудыг уншиж чадахгүй.
- Энэ бүхэн экосистемд ихээхэн нөлөө үзүүлж, гайхалтай өссөн. Багцууд нь хоорондоо нийцэхгүй байна: зарим нь амлалт дээр суурилдаг, зарим нь асинхронгуй/хүлээлт дээр суурилдаг, зарим нь буцаан дуудлага дээр суурилдаг. Тэд бас өөр өөр парадигмаар бичдэг!
- Энэ нь төслийг арчлахад хэцүү болгодог. Хэрэв та кодыг уншиж чадахгүй бол алдаа олоход хэцүү байдаг.
Вэб Ассемблей гэж юу вэ?
Mozilla Foundation болон бусад хэд хэдэн компаниудын зоригтой залуус Web Assembly гэх мэт зүйлийг гаргаж ирэв. Энэ юу вэ?
- Энэ бол хоёртын форматыг дэмждэг хөтөч дээр суурилагдсан виртуал машин юм.
- Хоёртын програмууд тэнд очдог бөгөөд бараг эх хувиараа ажилладаг, өөрөөр хэлбэл хөтөч нь javascript кодын бүх "гоймон" -ыг цаг бүр задлах шаардлагагүй болно.
- Бүх хөтчүүд дэмжлэгээ зарласан.
- Энэ нь байт код тул та ямар ч хэлний хөрвүүлэгч бичиж болно.
- Дөрвөн томоохон хөтөч аль хэдийн Вэб Ассемблей дэмжлэгтэйгээр нийлүүлэгдсэн.
- Бид удахгүй Go-д уугуул дэмжлэг хүлээж байна. Энэхүү шинэ архитектурыг аль хэдийн нэмсэн: GOARCH=wasm GOOS=js (удалгүй). Одоохондоо миний ойлгож байгаагаар энэ нь ажиллахгүй байгаа ч Go-д байх нь гарцаагүй гэсэн мэдэгдэл байдаг.
Одоо юу хийх вэ? GopherJS
Бид Вэб Ассемблейг дэмждэггүй ч GopherJS шиг дамжуулагч байдаг.
- Go код нь "цэвэр" Javascript руу хөрвүүлэгддэг.
- Бүх хөтөч дээр ажилладаг - зөвхөн орчин үеийн хөтчүүдээр дэмжигдэх шинэ боломж байхгүй (энэ нь ямар ч зүйл дээр ажилладаг Vanilla JS).
- Go-д байгаа бараг бүх зүйл, түүний дотор горутин, суваг... бидний маш их хайрладаг, мэддэг бүх зүйлд дэмжлэг байдаг.
- Хөтөч дээр дэмжих нь утгагүй багцуудаас бусад стандарт номын санг бараг бүхэлд нь дэмждэг: syscall, net харилцан үйлчлэл (net/http клиент байдаг, гэхдээ сервер байхгүй, үйлчлүүлэгчийг XMLHttpRequest-ээр дуурайлган хийдэг). Ерөнхийдөө стандарт номын сан бүхэлдээ байдаг - энд хөтөч дээр байгаа, энд бидний дуртай Go-ийн stdlib байна.
- Go дахь багцын экосистемийг бүхэлд нь, гуравдагч талын бүх шийдлүүдийг (загвар хийх гэх мэт) GopherJS ашиглан хөрвүүлж, хөтөч дээр ажиллуулж болно.
GopherJS-ийг авахад маш хялбар байдаг - энэ нь ердийн Go багц юм. Бид очоод авах ба програмыг бүтээх GopherJS тушаал байна:
Энэ бол ийм жижигхэн сайхан ертөнц юм ...
...Ердийн Go програм, ердийн стандарт номын сангийн fmt багц болон хөтчийн API-д хүрэх Binding Js. Println нь эцэст нь консолын бүртгэл рүү хөрвүүлэх бөгөөд хөтөч нь "Сайн уу gophers" гэж бичих болно! Энэ нь маш энгийн: бид GopherJS-ийг бүтээдэг - бид үүнийг хөтөч дээр ажиллуулдаг - бүх зүйл ажилладаг!
Яг одоо танд юу байгаа вэ? Холболт
Бүх алдартай js фреймворкуудад зориулсан холбоосууд байдаг:
- JQuery;
- Angular.js;
- Том өгөгдөлтэй ажиллах, график зурах D3.js;
- React.js;
- VueJS;
- бүр Electron-ийн дэмжлэг байдаг (өөрөөр хэлбэл бид Electron дээр ширээний програм бичиж болно);
- хамгийн хөгжилтэй нь WebGL (бид 3D график бүхий тоглоом, хөгжим, бүх сайхан зүйлсийг багтаасан бүрэн график програмуудыг хийх боломжтой);
- бүх алдартай javascript фреймворк болон номын сантай холбоотой бусад олон холболтууд.
тогтолцоо
- GopherJS - Vecty-д зориулж тусгайлан боловсруулсан вэб хүрээ бий. Энэ нь React.js-ийн бүрэн хэмжээний аналог боловч GopherJS-ийн онцлогтой зөвхөн Go программ дээр боловсруулагдсан.
- Тоглоомын уут байдаг (гайхах!). Би хамгийн алдартай хоёрыг олсон:
- Энго;
- Эбитэн.
Би танд Go дээр ямар харагдах, юу бичиж болохыг хэд хэдэн жишээгээр харуулах болно:
Эсвэл энэ сонголт (би 3D мэргэн бууч олж чадсангүй, гэхдээ энэ нь байж магадгүй):
Би юу санал болгож байна вэ?
Одоо урд талын салбар ийм байдалд байгаа бөгөөд өмнө нь Javascript-ээс уйлж байсан бүх хэлүүд тийшээ яарах болно. Одоо бүх зүйлийг "Вэб Ассемблей" болгон нэгтгэх болно. Гоферуудын хувьд бид тэнд зохих байр сууриа эзлэхэд юу хэрэгтэй вэ?
Go нь уламжлал ёсоор үүнийг Системийн програмчлалын хэл гэж үздэг бөгөөд UI-тай ажиллах номын сан бараг байдаггүй. Ямар нэг зүйл байдаг, гэхдээ энэ нь хагас хаягдсан, тал нь ажиллахгүй байна.
Одоо Go-д GopherJS дээр ажиллах UI номын сан хийх сайхан боломж байна! Та эцэст нь өөрийн хүрээг бичиж болно! Энэ бол та фреймворк бичиж чадах үе бөгөөд энэ нь анхныхуудын нэг бөгөөд эрт үрчлүүлэх бөгөөд та од болно (хэрэв энэ нь сайн хүрээ юм бол).
Та Go экосистемд байгаа олон төрлийн багцуудыг хөтчийн онцлогт тохируулж болно (жишээ нь, Template хөдөлгүүр). Тэд аль хэдийн ажиллах болно, та тохиромжтой холбоосуудыг хийж, контентыг шууд хөтөч дээр хялбархан үзүүлэх боломжтой. Нэмж дурдахад, та жишээлбэл, сервер болон урд талдаа ижил зүйлийг үзүүлэх үйлчилгээг ижил код ашиглан хийж болно - урд талын хөгжүүлэгчдэд таалагддаг бүх зүйл (зөвхөн Go дээр).
Та тоглоом бичиж болно! Зүгээр л зугаацахын тулд…
Үүнийг л хэлэхийг хүссэн юм.
Асуултууд
Асуулт (цаашид Q гэх): – Би Go эсвэл Js дээр бичдэг үү?
AG: – Та дэг журам, суваг, бүтэц, оруулах – бүгдийг Go-д бичдэг... Та үйл явдалд бүртгүүлж, тэнд функц дамжуулдаг.
Дотор нь: – Тэгэхээр би “нүцгэн” Js-ээр бичдэг юм уу?
AG: – Үгүй ээ, та Go дээр байгаа юм шиг бичээд хөтчийн API-д холбогдоно (API өөрчлөгдөөгүй). Суваг руу мессеж илгээхийн тулд та өөрийн холбоосыг бичиж болно - энэ нь хэцүү биш юм.
Дотор нь: -Гар утасны тухайд?
AG: – Би гарцаагүй харсан: Js-ийн ажиллуулдаг Кордова нөхөөсийн бэхэлгээ байдаг. React Native-д - би мэдэхгүй; магадгүй байгаа, магадгүй үгүй (би тийм ч их сонирхоогүй). N-go тоглоомын хөдөлгүүр нь iOS болон Android гэсэн гар утасны програмуудыг хоёуланг нь дэмждэг.
Дотор нь: – Вэб Ассемблейтэй холбоотой асуулт. Хэдийгээр шахаж, "зип" хийсэн ч илүү их зай эзэлсээр байна ... Бид урд талын ертөнцийг ингэж алах биш гэж үү?
AG: – Web Assembly нь хоёртын формат бөгөөд анхдагчаар хоёртын хувилбар нь текстээс илүү эцсийн хувилбарт байх боломжгүй... Та ажиллах цаг руу татагдсан боловч энэ нь стандарт Javascript номын санг байхгүй үед чирж гаргахтай адил юм. бага зэрэг Лодаш ашигла. Лодаш хэдэн төгрөг авдаг юм бүү мэд.
Дотор нь: – Ажиллах хугацаанаас бага байх нь ойлгомжтой...
AG: – “Цэвэр” Javascript дээр үү?
Дотор нь: - Тийм ээ. Бид үүнийг илгээхээсээ өмнө шахдаг ...
AG: – Гэхдээ энэ бол текст... Ерөнхийдөө мегабайт нь их юм шиг санагддаг, гэхдээ энэ нь (та бүхэл бүтэн ажиллах хугацаатай). Дараа нь та өөрийн бизнесийн логикийг бичих бөгөөд энэ нь таны хоёртын хувилбарыг 1% -иар нэмэгдүүлэх болно. Одоохондоо энэ нь урд талын хэсгийг устгаж байгааг би хараагүй байна. Үүнээс гадна, Web Assembly нь тодорхой шалтгааны улмаас Javascript-ээс хурдан ажиллах болно - үүнийг задлан шинжлэх шаардлагагүй.
Дотор нь: – Энэ бол маргаантай асуудал хэвээр байна... Хоёрдмол утгагүй дүгнэлт хийх боломжтой “Васма” (Вэб Ассемблей) хэрэглүүр хараахан гараагүй байна. Үзэл баримтлалын хувьд, тийм: бид бүгд хоёртын систем нь илүү хурдан байх ёстой гэдгийг ойлгож байгаа боловч ижил V8-ийн одоогийн хэрэгжилт нь маш үр дүнтэй байдаг.
AG: - Тийм ээ.
Дотор нь: - Тэнд эмхэтгэх нь үнэхээр гайхалтай ажилладаг бөгөөд том давуу талтай байх нь үнэн биш юм.
AG: – Веб ассемблейг бас томчууд хийдэг.
Дотор нь: – Вэб Ассемблейг шүүх хэцүү хэвээр байх шиг байна. Олон жил яриа өрнүүлсэн ч мэдрэгдэх бодит ололт бага байна.
AG: - Магадгүй. Бид харна.
Дотор нь: – Бидэнд арын хэсэгт асуудал байхгүй... Магадгүй бид эдгээр асуудлуудыг урд талд үлдээх хэрэгтэй болов уу? Яагаад тийшээ явах вэ?
AG: – Бид тэргүүн эгнээний ажилчдын орон тоог байлгах ёстой.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй,
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд
Эх сурвалж: www.habr.com