Kyiv Go Meetup May 2018:
вядучы: - Ўсім прывітанне! Дзякуй, што вы тут сабраліся! Сёння ў нас два афіцыйныя спікеры – Лёша і Ваня. Будзе яшчэ два, калі хопіць часу. Першы спікер - Аляксей Грачоў, ён раскажа нам пра GopherJS.
Аляксей Грачоў (далей - АГ): - Я - Go-дэвелапер, і я пішу вэб-сэрвісы на Go. Часам даводзіцца сутыкацца з франтэндам, часам даводзіцца залазіць туды ручкамі. Жадаю распавесці аб сваім досведзе і даследаваннях Go на франтэндзе.
Легенда такая: спачатку пагаворым, чаму мы жадаем запускаць Go на франтэндзе, потым пагаворым, як гэта можна зрабіць. Ёсць два шляхі - Web Assembly і GopherJS. Паглядзім, у якім стане гэтыя рашэньні і што можна рабіць.
Што не так з frontend-ым?
Усе згодны, што ўсё добра з франтэндам?
Тэстаў мала? Павольная зборка? Экасістэма? Добра.
Наконт фронтэнда мне падабаецца цытата, якую сказаў адзін з фронтэнд-распрацоўшчыкаў у сваёй кнізе:
У Javascript няма сістэмы тыпаў. Цяпер я буду называць праблемы, з якімі сутыкаўся падчас сваёй працы і тлумачыць, як іх вырашаюць.
Сістэму тыпаў наогул цяжка назваць сістэмай тыпаў у Javasript - там ёсць радкі, якія абазначаюць тып аб'екта, але на самой справе да тыпаў гэта не мае ніякага дачынення. Гэтая праблема вырашана ў TypeScript (надбудова над Javasript) і Flow (static-checker тыпаў у Javascript). Уласна, фронтэнд ужо дайшоў да рашэння праблемы дрэннай сістэмы тыпаў у Javascript.
Стандартнай бібліятэкі ў браўзэры як такой няма - ёсць нейкія ўбудаваныя аб'екты і "магічныя" функцыі ў браўзэрах. Але я ў Javascript як такім стандартная бібліятэка адсутнічае. Гэта праблема ўжо была калісьці вырашана jQuery (усе выкарыстоўвалі jQuery са ўсімі прататыпамі, хелперамі, функцыямі, якія патрэбныя для працы). Цяпер жа ўсё выкарыстоўваюць Lodash:
Callback hell. Думаю, усё бачылі код на Javascript дзесьці 5 гадоў назад, і ён быў падобны на «локшыну» з неверагоднага хітраспляцення коллбэкаў. Цяпер гэтая праблема вырашана (з выхадам ES-15 ці ES-16), дадалі ў Javascript промисы (promises) і ўсім стала дыхаць лягчэй на нейкі час.
Пакуль не прыйшоў Promice hell… Не ведаю, як фронтэнд-індустрыя прымудраецца, але яны ўвесь час заганяюць сябе ў нейкія дзіўныя нетры. Умудрыліся і на «промісах» зрабіць hell. Потым вырашылі гэтую праблему, дадаўшы новы прымітыў - async/await:
З асінхроннасцю праблема вырашана. Async/await – дастаткова папулярны прымітыў у розных мовах. У «Пітоне» і ў іншых ёсць такі падыход - ён дастаткова добры. Праблема вырашана.
Якая праблема не вырашана? Якая ўзрастае ў геаметрычнай прагрэсіі складанасць фрэймворкаў, складанасць экасістэмы і ўласна праграм.
- Сінтаксіс Javasript крыху дзіўны. Усе мы ведаем праблемы са складаннем масіва і аб'екта і іншыя прыколы.
- Javascript - мультыпарадгменны. Цяпер гэта асабліва надзённая сістэма, калі экасістэма вельмі вялікая:
- усё пішуць у розных стылях - хтосьці піша структурна, хтосьці піша функцыянальна, розныя дэвелаперы пішуць па-рознаму;
- з розных пэкэджаў (packages) розныя парадыгмы, калі вы выкарыстоўваеце розныя пакеты;
- вельмі шмат "весялосці" з функцыянальным праграмаваннем у Javasript – з'явілася бібліятэка rambda і зараз чытаць праграмы, напісаныя ў гэтай бібліятэцы, не можа ніхто.
- Гэта ўсё ўносіць вялікі impact у экасістэму, і яна разраслася неверагодна. Пакеты адзін з адным несумяшчальныя: хтосьці - на промісах, хтосьці - на async / await, хтосьці - на коллбэках. Яшчэ і ў розных парадыгмах пішуць!
- Гэта прыводзіць да таго, што праект цяжка падтрымліваць. Складана знайсці баг, калі ты не можаш прачытаць код.
Што такое Web Assemly?
Бравыя хлопцы з Mozilla Foundation і шэрагу іншых кампаній прыдумалі такую рэч, як Web Assembly. Што гэта?
- Гэта ўбудаваная ў браўзэр віртуальная машына, якая падтрымлівае бінарны фармат.
- Бінарныя праграмы туды пападаюць, выконваюцца практычна натыўна, гэта значыць браўзэру не трэба кожны раз парсіць усю «локшыну» javascript-кода.
- Усе браўзэры заявілі аб падтрымцы.
- Паколькі гэта байт-код, можна напісаць кампілятар пад любую мову.
- Чатыры асноўныя браўзэры ўжо пастаўляюцца з падтрымкай Web Assembly.
- Хутка мы чакаем натыўнай падтрымкі ў Go. Такая новая архітэктура ўжо дадалася: GOARCH = wasm GOOS = js (soon). Пакуль, як я разумею, яна не функцыянальная, аднак ёсць заява аб тым, што гэта сапраўды будзе ў Go.
Што рабіць зараз? GopherJS
Пакуль у нас няма падтрымкі Web Assembly, ёсць такі транспайлер, як GopherJS.
- Код на Go транспайліцца ў "чысты" Javascript.
- Запускаецца ва ўсіх браўзэрах - там няма новых фіч, якія падтрымліваюцца толькі сучаснымі браўзэрамі (гэта Vanilla JS, які запускаецца на ўсім чым заўгодна).
- Ёсць падтрымка амаль усяго, што ёсць у Go, у тым ліку гаруціны і каналы… – усё, што мы так любім і ведаем.
- Амаль уся стандартная бібліятэка падтрымліваецца, за выключэннем тых пакетаў, якія не мае сэнсу падтрымліваць у браўзэры: syscall, net-узаемадзеянні (ёсць net/http-кліент, але няма сервера, а кліент эмулюецца праз XMLHttpRequest). У цэлым уся стандартная бібліятэка даступная - вось яна ў браўзэры, вось stdlib Go, якую мы кахаем.
- Уся экасістэма пакета ў Go, усе іншыя рашэнні (тэмплейтынг і інш.) можна скампіляваць з дапамогай GopherJS і запусціць гэта ў браўзэры.
Атрымаць GopherJS вельмі лёгка - гэта звычайны Go-пакет. Робім go get, і ў нас ёсць каманда GopherJS, каб білдзіць прыкладанне:
Вось такі маленькі hello world…
…Звычайная Go-праграма, звычайны пакет fmt стандартнай бібліятэкі і Binding Js, каб дагрукацца да API браўзэра. Println у выніку будзе пераўтвораны ў console log і браўзэр напіша "Hello gophers"! Вось так проста: які робіцца GopherJS build - запускаем у браўзэры - усё працуе!
Што ёсць зараз? Bindings
Ёсць бiндiнгi да ўсiх папулярных js-фрэймворкаў:
- JQuery;
- Angular.js;
- D3.js для пабудовы графікаў і працы з вялікімі дадзенымі;
- React.js;
- VueJS;
- нават ёсць падтрымка Electron (гэта значыць ужо цяпер можам пісаць дэсктопныя прыкладанні на «Электроне»);
- і самае пацешнае - гэта WebGL (можам рабіць поўнаграфічныя прыкладанні, у тым ліку гульні з 3D-графікай, музыкай і ўсімі плюшкамі);
- і вельмі шмат іншых біндзінгаў да ўсіх папулярных javascript-фрэймворкаў і бібліятэкам.
Рамкі
- Ёсць ужо распрацаваны спецыяльна для GopherJS вэб-фрэймворк - Vecty. Гэта паўнавартасны аналаг React.js, але толькі распрацаваны на Go, са спецыфікай GopherJS.
- Ёсць гульнявыя мяшкі (раптоўна!). Я знайшоў два самых папулярных:
- Engo;
- Ebiten.
Прадэманструю пару прыкладаў, як гэта выглядае і што ўжо зараз можна напісаць на Go:
Або такі варыянт (3D-шутэр не знайшоў, але, можа, ён ёсць):
Што я прапаную?
Цяпер індустрыя фронтэнда знаходзіцца ў такім стане, што туды зараз рынуцца ўсе мовы, якія да гэтага плакалі ад Javascript. Зараз усе будуць кампілявацца ў "Вэб Асэмблі". Што нам трэба, каб заняць там дастойнае месца як «гоферам»?
У Go традыцыйна пайшло, што гэта - System programming language, і практычна няма ніякіх бібліятэк для працы з UI. Нешта ёсць, але яно напалову закінутае, напалову нефункцыянальнае.
І вось - добры шанец зрабіць UI-бібліятэкі на Go, якія будуць запускацца на GopherJS! Можна, нарэшце, напісаць свой фрэймворк! Наступіў той час, калі можна напісаць фрэймворк, і ён будзе адным з першых і атрымае раннюю адаптацыю, і вы будзеце зоркай (калі гэта будзе добры фрэймворк).
Адаптаваць можна процьму розных пакетаў, якія ўжо ёсць у экасістэме Go, да спецыфікі браўзэра (напрыклад, Template engine). Яны дык вось, ужо запрацуюць, можна зрабіць зручныя абвязкі, каб можна было лёгка рэндэрыць кантэнт прама ў браўзэры. Плюс, можна зрабіць, напрыклад, сэрвіс, які ўмее рэндэрыць тое ж самае на серверы і на франтэндзе, выкарыстоўваючы адзін і той жа код – усё як любяць фронтэнд-дэвелаперы (толькі зараз на Go).
Можна напісаць гульню! Just for fun…
У мяне ўсё.
пытанні
Пытанне (далей - У): - Я пішу на Go або на Js?
АГ: – Ты пішаш на Go руціны, каналы, структуры, embedding – усё… Ты падпісваешся на event, перадаеш туды функцыю.
У: – Гэта значыць, я пішу на «галом» Js?
АГ: - Не, ты пішаш як бы на Go і падлучаешся да API браўзэра (API пры гэтым не змяніўся). Можаш напісаць свае абвязкі, каб у канал прыходзілі паведамленні - гэта ж нескладана.
У: – Што наконт мабайла?
АГ: - Я сапраўды бачыў: ёсць біндынгі для патча Cordova, якія Js запускае. У React Native не ведаю; можа, ёсць, а можа, не (не асабліва цікавіўся). Гульнявы рухавічок N-go падтрымлівае і мабільныя прыкладанні - і iOs, і Android.
У: - Пытанне па Web Assembly. Месца займаецца ўсё больш, нягледзячы на сціснутасць, «зазіпаванасць»… Ці не заб'ем такім чынам свет фронтэнда яшчэ больш?
АГ: – Web Assembly – гэта бінарны фармат, і бінарны па змаўчанні не можа быць у выніковым рэлізе больш, чым тэкст… Вас цягне runtime, але гэта тое ж самае, што стандартную бібліятэку Javascript зацягнуць, калі яе няма, таму мы выкарыстоўваем які-небудзь Lodash . Я не ведаю, колькі Lodash займае.
У: – Відавочна менш, чым runtime…
АГ: - На «чыстым» Javascript?
У: - Так. Мы ж яго сціскаем перад тым, як адпраўляць…
АГ: - Але гэта ж тэкст… Увогуле, мегабайт - гэта накшталт шмат, але гэта - усё (у цябе ўвесь runtime ёсць). Далей ты пішаш сваю бізнэс-логіку, якая павялічыць на 1% твой binary. Пакуль я не бачу, каб гэта забівала фронтэнд. Тым больш Web Assembly будзе працаваць хутчэй, чым Javascript па відавочнай прычыне - яго не трэба парсіць.
У: – Пакуль спрэчны момант… Яшчэ няма нейкай эталоннай рэалізацыі “Васма” (Web Assembly), каб можна было адназначна меркаваць. Канцэптуальна так: мы ўсё разумее, што binary павінен быць хутчэй, але бягучая рэалізацыя таго ж V8 вельмі эфектыўная.
АГ: - Так.
У: - Кампіляцыя там працуе рэальна вельмі крута і не факт, што будзе вялікая перавага.
АГ: - Web Assembly таксама вялікія дзядзькі робяць.
У: - Пакуль, мне здаецца, яшчэ цяжка меркаваць аб Web Assembly. Ужо колькі гадоў ідуць размовы, а рэальных дасягненняў, якія можна памацаць, няшмат.
АГ: - Магчыма. Будзем паглядзець.
У: – У нас няма праблем на бэкендзе… Можа, пакінуць гэтыя праблемы ў франтэндзе? Навошта туды лезці?
АГ: - Даводзіцца трымаць штат францейнераў.
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com