Kyiv Go Meetup мај 2018 година:
Водач: - Здраво на сите! Ви благодариме што сте тука! Денес имаме двајца официјални говорници - Лиоша и Вања. Ќе има уште два ако имаме доволно време. Првиот говорник е Алексеј Грачев, ќе ни каже за GopherJS.
Алексеј Грачев (во натамошниот текст – А.Г.): – Јас сум развивач на Go и пишувам веб-услуги во Go. Понекогаш треба да се справите со предниот дел, понекогаш мора да се вклучите во него рачно. Сакам да зборувам за моето искуство и истражување за Go on the frontend.
Легендата е следна: прво ќе разговараме зошто сакаме да го извршиме Go на предниот дел, а потоа ќе разговараме за тоа како може да се направи тоа. Постојат два начина - Web Assembly и GopherJS. Ајде да видиме каков е статусот на овие решенија и што може да се направи.
Што не е во ред со предниот дел?
Дали сите се согласуваат дека сè е во ред со предниот дел?
Дали нема доволно тестови? Бавна градба? Екосистем? Добро.
Во врска со фронтендот, ми се допаѓа цитатот што еден од развивачите на фронтендот го кажа во својата книга:
Javascript нема систем за типови. Сега ќе ги именувам проблемите со кои наидов во текот на мојата работа и ќе објаснам како се решаваат.
Системот за типови воопшто тешко може да се нарече типски систем во Javasript - има линии што го означуваат типот на објектот, но всушност тоа нема никаква врска со типовите. Овој проблем е решен во TypeScript (додаток на Javasript) и Flow (проверка на статички тип во Javascript). Всушност, предниот дел веќе достигна точка да го реши проблемот со лош тип систем во Javascript.
Не постои стандардна библиотека во прелистувачот како таква - има некои вградени објекти и „магични“ функции во прелистувачите. Но, во Javascript не постои стандардна библиотека како таква. Овој проблем веќе еднаш беше решен од jQuery (сите користеа jQuery со сите прототипови, помошници, функции кои беа потребни за работа). Сега сите користат Lodash:
Повратен повик пекол. Мислам дека сите го видоа Javascript кодот пред околу 5 години и изгледаше како „нудла“ од неверојатна сложеност на повратни повици. Сега овој проблем е решен (со излегувањето на ES-15 или ES-16), ветувањата се додадени на Javascript и секој може да дише полесно за некое време.
Сè додека не дојде пеколот на Promise... Не знам како се справува со напредната индустрија, но тие секогаш се возат во некоја чудна џунгла. Успеавме да направиме и пекол на ветувањата. Потоа го решивме овој проблем со додавање на нов примитив - async/wait:
Проблемот со асинхронијата е решен. Async/wait е прилично популарен примитив на различни јазици. Пајтон и другите го имаат овој пристап - тоа е доста добро. Проблемот е решен.
Кој проблем не е решен? Експоненцијално зголемената сложеност на рамки, сложеноста на екосистемот и самите програми.
- Синтаксата на Javascript е малку чудна. Сите ги знаеме проблемите со додавање низа и објект и други шеги.
- Javascript е мулти-парадигма. Ова е особено итен систем сега кога екосистемот е многу голем:
- секој пишува во различни стилови - некои пишуваат структурно, некои пишуваат функционално, различни развивачи пишуваат на различни начини;
- од различни пакети, различни парадигми кога користите различни пакети;
- има многу „забава“ со функционалното програмирање во Javasript - се појави библиотеката rambda и сега никој не може да чита програми напишани во оваа библиотека.
- Сето ова има големо влијание врз екосистемот и тој неверојатно порасна. Пакетите се некомпатибилни еден со друг: некои се засноваат на ветувања, некои се засноваат на асинхронизирање/чекање, некои се засноваат на повратни повици. Тие исто така пишуваат во различни парадигми!
- Ова го отежнува одржувањето на проектот. Тешко е да се најде бубачка ако не можете да го прочитате кодот.
Што е Веб собрание?
Храбрите момци од фондацијата Mozilla и голем број други компании смислија нешто како Web Assembly. Што е ова?
- Ова е виртуелна машина вградена во прелистувачот што поддржува бинарен формат.
- Бинарните програми стигнуваат до таму и се извршуваат речиси природно, односно, прелистувачот не треба да ги анализира сите „нудли“ на Javascript-кодот секој пат.
- Сите прелистувачи објавија поддршка.
- Бидејќи ова е бајт-код, можете да напишете компајлер за кој било јазик.
- Четири главни прелистувачи веќе се испорачуваат со поддршка за Web Assembly.
- Наскоро очекуваме домашна поддршка во Go. Оваа нова архитектура е веќе додадена: GOARCH=wasm GOOS=js (наскоро). Досега како што разбрав не е функционален, но има изјава дека дефинитивно ќе биде во Го.
Што да се прави сега? GopherJS
Иако немаме поддршка за Web Assembly, постои транспајлер како GopherJS.
- Go кодот се преобразува во „чист“ Javascript.
- Работи во сите прелистувачи - нема нови функции што се поддржани само од модерни прелистувачи (ова е Vanilla JS, кој работи на било што).
- Има поддршка за речиси сè што има Go, вклучително и горутини и канали... се што толку многу сакаме и знаеме.
- Поддржана е речиси целата стандардна библиотека, освен оние пакети што нема смисла да се поддржуваат во прелистувачот: syscall, net интеракции (има net/http клиент, но нема сервер, а клиентот се емулира преку XMLHttpRequest). Во принцип, целата стандардна библиотека е достапна - тука е во прелистувачот, тука е stdlib на Go, што го сакаме.
- Целиот пакет екосистем во Go, сите решенија од трети страни (шаблони, итн.) може да се компајлираат со помош на GopherJS и да се извршуваат во прелистувачот.
GopherJS е многу лесно да се добие - тоа е само обичен Go пакет. Одиме да добиеме и имаме команда GopherJS за да ја изградиме апликацијата:
Ова е толку мал здрав свет...
...Редовна Go програма, редовен стандарден пакет fmt на библиотека и Binding Js за да се стигне до API на прелистувачот. Println на крајот ќе се претвори во дневник на конзолата и прелистувачот ќе напише „Здраво Gophers“! Толку е едноставно: правиме изградба на GopherJS - го стартуваме во прелистувачот - сè работи!
Што имате во моментот? Поврзувања
Постојат врски за сите популарни js рамки:
- JQuery;
- Angular.js;
- D3.js за исцртување и работа со големи податоци;
- React.js;
- VueJS;
- има дури и поддршка за Electron (односно, веќе можеме да пишуваме десктоп апликации на Electron);
- а најсмешното нешто е WebGL (можеме да правиме целосно графички апликации, вклучувајќи игри со 3D графика, музика и сите добрини);
- и многу други врзувања за сите популарни JavaScript рамки и библиотеки.
Рамка
- Постои веб-рамка веќе развиена специјално за GopherJS - Vecty. Ова е полноправен аналог на React.js, но развиен само во Go, со спецификите на GopherJS.
- Има торби за игра (изненадување!). Ги најдов двете најпопуларни:
- Енго;
- Ебитен.
Ќе ви покажам неколку примери за тоа како изгледа и што веќе можете да напишете во Go:
Или оваа опција (не можев да најдам 3D стрелец, но можеби постои):
Што нудам?
Сега предната индустрија е во таква состојба што сите јазици што претходно плачеа од Javascript ќе брзаат таму. Сега сè ќе биде составено во „Веб собранија“. Што ни треба за да го заземеме вистинското место таму како Gophers?
Go традиционално претпоставува дека е системски програмски јазик и практично нема библиотеки за работа со UI. Има нешто, но тоа е половина напуштено, половина нефункционално.
И сега е добра шанса да се направат библиотеки за интерфејс во Go што ќе работат на GopherJS! Конечно можете да напишете своја рамка! Ова е време кога можете да напишете рамка, и таа ќе биде една од првите и ќе добие рано усвојување, а вие ќе бидете ѕвезда (ако е добра рамка).
Можете да прилагодите многу различни пакети кои веќе се во екосистемот Go на спецификите на прелистувачот (на пример, Шаблон мотор). Тие веќе ќе работат, можете да направите пригодни врзувања за да можете лесно да ја прикажувате содржината директно во прелистувачот. Плус, можете да направите, на пример, услуга што може да го прикажува истото на серверот и на предниот дел, користејќи го истиот код - сè што им се допаѓа на програмерите од предниот дел (само сега во Go).
Можете да напишете игра! Само за забава...
Тоа е се што сакав да кажам.
прашања
Прашање (во натамошниот текст: П): – Дали пишувам во Go или Js?
АГ: – Пишувате рутини, канали, структури, вградување – сè во Go... Се претплатите на настан, поминувате функција таму.
НА: – Па јас пишувам во „голи“ Џс?
АГ: – Не, пишувате како во Go и се поврзувате со API на прелистувачот (API не е променет). Можете да напишете свои обврзници за да се испраќаат пораки до каналот - не е тешко.
НА: – Што е со мобилниот?
АГ: – Дефинитивно видов: има врзувачки за закрпата Cordova што ја извршува Js. Во React Native - не знам; можеби има, можеби не (не бев особено заинтересиран). Моторот за игри N-go ги поддржува двете мобилни апликации - и iOS и Android.
НА: – Прашање за Web Assembly. Сè повеќе простор се зафаќа, и покрај компресија и „ципање“... Зарем на овој начин уште повеќе нема да го убиеме предниот свет?
АГ: – Web Assembly е бинарен формат, а бинарното по дифолт не може да биде во последното издание повеќе од текст... Ве привлекува време на траење, но ова е исто како да ја влечете стандардната библиотека Javascript кога ја нема, така што ние користете малку Lodash. Не знам колку зема Лодаш.
НА: – Очигледно помалку од траење...
АГ: – Во „чист“ Javascript?
НА: - Да. Го компресираме пред да го испратиме...
АГ: – Но, ова е текст... Во принцип, мегабајтот изгледа како многу, но тоа е сè (го имате целото време на траење). Следно, вие пишувате своја сопствена деловна логика, која ќе ја зголеми вашата бинарност за 1%. Засега не гледам дека ова го убива предниот дел. Покрај тоа, Web Assembly ќе работи побрзо од Javascript од очигледна причина - не треба да се анализира.
НА: – Ова е сè уште контроверзна точка... Сè уште нема референтна имплементација на „Васма“ (Веб собрание) за да може недвосмислено да се суди. Концептуално, да: сите разбираме дека бинарното треба да биде побрзо, но сегашната имплементација на истиот V8 е многу ефикасна.
АГ: - Да.
НА: – Компилацијата таму работи навистина многу кул и не е факт дека ќе има голема предност.
АГ: – Веб собранието го прават и големи момци.
НА: – Ми се чини дека сè уште е тешко да се суди Web Assembly. Има разговори веќе долги години, но има малку вистински достигнувања што може да се почувствуваат.
АГ: - Можеби. Ќе видиме.
НА: – Немаме проблеми на заднината... Можеби треба да ги оставиме овие проблеми на предниот дел? Зошто да одам таму?
АГ: – Мораме да задржиме персонал од првите редови.
Некои реклами 🙂
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB DDR4).
Dell R730xd 2 пати поевтин во центарот за податоци Equinix Tier IV во Амстердам? Само овде во Холандија! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - од 99 долари! Прочитајте за
Извор: www.habr.com