Kyiv Go Meetup May 2018:
Ведущий: – Всем привет! Спасибо, что вы здесь собрались! Сегодня у нас два официальных спикера – Лёша и Ваня. Будет ещё два, если у нас хватит времени. Первый спикер – Алексей Грачёв, он расскажет нам о GopherJS.
Алексей Грачёв (далее – АГ): – Я – Go-девелопер, и я пишу веб-сервисы на Go. Порой приходится сталкиваться с фронтендом, иногда приходится залазить туда ручками. Хочу рассказать о своём опыте и исследованиях Go на фронтенде.
Легенда такая: сначала поговорим, почему мы хотим запускать Go на фронтенде, потом поговорим, как это можно сделать. Есть два пути – Web Assembly и GopherJS. Посмотрим, в каком состоянии эти решения и что можно делать.
Что не так с frontend-ом?
Все согласны, что всё хорошо с фронтендом?
Тестов мало? Медленная сборка? Экосистема? Хорошо.
По поводу фронтенда мне нравится цитата, которую сказал один из фронтенд-разработчиков в своей книге:
В Javascript нет системы типов. Сейчас я буду называть проблемы, с которыми сталкивался по ходу своей работы и объяснять, как их решают.
Систему типов вообще трудно назвать системой типов в Javascript – там есть строки, которые обозначают тип объекта, но на самом деле к типам это не имеет никакого отношения. Эта проблема решена в TypeScript (надстройка над Javascript) и Flow (static-checker типов в Javascript). Собственно, фронтенд уже дошёл до решения проблемы плохой системы типов в Javascript.
Стандартной библиотеки в браузере как таковой нет – есть какие-то встроенные объекты и «магические» функции в браузерах. Но я в Javascript как таковом стандартная библиотека отсутствует. Эта проблема уже была когда-то решена jQuery (все использовали jQuery со всеми прототипами, хелперами, функциями, которые нужны для работы). Сейчас же все используют Lodash:
Callback hell. Думаю, все видели код на Javascript где-то 5 лет назад, и он был похож на «лапшу» из невероятного хитросплетения коллбэков. Сейчас эта проблема решена (с выходом ES-15 или ES-16), добавили в Javascript промисы (promises) и всем стало дышать полегче на какое-то время.
Пока не пришёл Promise hell… Не знаю, как фронтенд-индустрия умудряется, но они всё время загоняют себя в какие-то странные дебри. Умудрились и на «промисах» сделать hell. Потом решили эту проблему, добавив новый примитив – async/await:
Problem with asynchronicity is resolved. Async/await is a fairly popular primitive in various languages. Python and others have such an approach – it is quite good. The problem is solved.
What problem remains unsolved? The exponentially increasing complexity of frameworks, the complexity of the ecosystem, and the programs themselves.
- The syntax of Javascript is a bit strange. We all know the issues with adding arrays and objects and other quirks.
- Javascript is multiparadigm. This is particularly relevant now, as the ecosystem is very large:
- everyone writes in different styles – some write structurally, others write functionally, different developers write differently;
- from different packages, different paradigms emerge when you use various packages;
- there's a lot of 'fun' with functional programming in Javascript – the library ramda appeared, and now no one can read programs written in that library.
- This all has a big impact on the ecosystem, and it has grown tremendously. Packages are incompatible with each other: some use promises, some use async/await, and some use callbacks. Also, they write in different paradigms!
- This leads to the project being difficult to maintain. It's hard to find bugs if you can't read the code.
What is Web Assembly?
Brave folks from the Mozilla Foundation and several other companies have come up with something called Web Assembly. What is it?
- It's a built-in virtual machine in the browser that supports a binary format.
- Binary programs are run there almost natively, meaning the browser doesn't have to parse all that 'noodles' of javascript code every time.
- All browsers have declared support.
- Since this is bytecode, you can write a compiler for any language.
- The four main browsers already come with support for Web Assembly.
- Soon, we expect native support in Go. Such a new architecture has already been added: GOARCH=wasm GOOS=js (soon). For now, as I understand, it's not functional, but there's a statement that it will definitely be in Go.
What should we do now? GopherJS
While we don't have support for Web Assembly, there is a transpiler called GopherJS.
- Code in Go is transpiled into 'pure' Javascript.
- It runs in all browsers – there are no new features that are only supported in modern browsers (this is Vanilla JS, which runs on anything).
- Podpiramo skoraj vse, kar je v Go, vključno z gorutinami in kanali... – vse, kar imamo radi in kar poznamo.
- Skoraj celotna standardna knjižnica je podprta, razen tistih paketov, katerih podpora v brskalniku nima smisla: syscall, omrežne interakcije (imamo net/http klienta, a strežnika ni, klient pa se emulira preko XMLHttpRequest). Na splošno je celotna standardna knjižnica na voljo – tukaj je v brskalniku, tukaj je stdlib Go, ki jo imamo radi.
- Vsa ekosistema paketa v Go, vse tretje rešitve (templating in druge) lahko prenesemo s pomočjo GopherJS in to zaženemo v brskalniku.
Pridobitev GopherJS je zelo enostavna – to je običajen Go paket. Naredimo go get, in imamo ukaz GopherJS za gradnjo aplikacije:
Tukaj je tak majhen hello world...
...Običajna Go aplikacija, običajen paket fmt iz standardne knjižnice in Binding Js, da dostopamo do API-ja brskalnika. Println se na koncu pretvori v console log in brskalnik izpiše "Pozdravljeni gopherji"! Tako preprosto: naredimo GopherJS build – zaženemo v brskalniku – vse deluje!
Kaj imamo trenutno? Bindings
Obstajajo bindings za vse priljubljene js-okvirje:
- JQuery;
- Angular.js;
- D3.js za ustvarjanje grafov in delo z velikimi podatki;
- React.js;
- VueJS;
- tudi podpira Electron (torej lahko že zdaj pišemo namizne aplikacije na "Elektronu");
- in kar je najzanimivejše – to je WebGL (lahko delamo polno grafične aplikacije, vključno z igrami s 3D grafiko, glasbo in vsemi dodatki);
- in še veliko drugih bindings za vse priljubljene javascript okvirje in knjižnice.
Okvir
- Obstoji že razviti spletni okvir namenjen posebej za GopherJS – Vecty. To je popoln analog React.js, vendar razvit na Go, z značilnostmi GopherJS.
- Ima tudi igralne okvirje (presenetljivo!). Našel sem dva najbolj priljubljena:
- Engo;
- Ebiten.
Prikažem vam nekaj primerov, kako to izgleda in kaj je že mogoče napisati na Go:
Ali torej taka možnost (nisem našel 3D strelca, a morda obstaja):
Kaj predlagam?
Trenutno je industrija frontenda v takem stanju, da se bodo vsi jeziki, ki so prej jokali zaradi Javascript, zdaj pognali tja. Zdaj se bodo vsi kompilirali v "Web Assembly". Kaj potrebujemo, da se tam dostojno uveljavimo kot "gopherji"?
V Go tradicionalno velja, da je to - sistemski programski jezik, in praktično ni nobenih knjižnic za delo z uporabniškim vmesnikom. Nekaj je, a je napol pozabljeno, napol nefunkcionalno.
In tako – odličen trenutek za ustvarjanje UI knjižnic v Go, ki se bodo zagnale na GopherJS! Končno lahko napišete svoj okvir! Prišel je čas, ko lahko napišete okvir, in bo eden prvih ter pridobil zgodnje sprejemanje, vi pa boste zvezda (če bo to dober okvir).
Adaptirati je mogoče ogromno različnih paketov, ki že obstajajo v Go ekosistemu, na specifične spletne brskalnike (na primer, predloge). Ti že delujejo, lahko pa naredimo udobne ovitke, da bo enostavno renderirati vsebino neposredno v brskalniku. Poleg tega lahko naredimo na primer storitev, ki zna renderirati isto tako na strežniku in na sprednjem delu, pri čemer se uporablja ista koda – vse, kar front-end razvijalci imajo radi (zdaj pač v Go).
Lahko napišete igro! Samo za zabavo…
To je vse z moje strani.
Vprašanja
Vprašanje (naprej – V): – Ali pišem v Go ali v Js?
AG: – Pišeš v Go rutine, kanale, strukture, vgradnjo – vse... Prijavljaš se na dogodek, prenašaš tja funkcijo.
V: – Torej pišem v 'golem' Js?
AG: – Ne, pišeš nekako v Go in se povezuješ z API-jem brskalnika (API se pri tem ni spremenil). Lahko napišeš svoje ovitke, da sporočila prihajajo v kanal – to ni težko.
V: – Kaj pa mobilne naprave?
AG: – Očitno sem videl: obstajajo vezave za patch Cordova, ki jih Js zažene. V React Native – ne vem; morda so, morda niso (nisem se preveč zanimal). Igralni motor N-go podpira tudi mobilne aplikacije – tako iOS kot Android.
V: – Vprašanje o Web Assembly. Prostor zaseda vse več, kljub stiskanju, 'zipanju'... Ali ne bomo na ta način še bolj uničili svet frontenda?
AG: – Web Assembly – to je binarni format, in binarni po privzetku ne more biti v končnem izidu večji kot tekst... Potegne vas runtime, a to je enako kot potegniti standardno JavaScript knjižnico, ko je ni, zato uporabljamo kakšen Lodash. Ne vem, koliko prostora vzame Lodash.
V: – Očitno manj, kot runtime…
AG: – Na 'čistem' JavaScriptu?
V: – Da. Stisnemo ga, preden ga pošljemo…
AG: – To, vendar, je besedilo… Na splošno, megabai so kar precejšnji, ampak to je vse (imaš cel runtime). Potem napišeš svojo poslovno logiko, ki bo povečala tvoj binary za 1 %. Zaenkrat ne vidim, da bi to uničilo frontend. Še posebej, ker bo Web Assembly deloval hitreje kot Javascript iz očitnega razloga – ni ga treba parsat.
V: – To je še vedno sporen trenutek… Ni še nekakšne standardne implementacije „Vasm“ (Web Assembly), da bi lahko nedvoumno sodili. Konceptualno – ja: vsi razumemo, da bi moral biti binary hitrejši, vendar je trenutna implementacija istega V8 zelo učinkovita.
AG: – Da.
V: – Komplilacija tam deluje res zelo dobro in ni nujno, da bo velika prednost.
AG: – Web Assembly tudi veliko močnih vplivnežev dela.
V: – Zdi se mi, da je še vedno težko presoditi o Web Assembly. Koliko let že govorimo, pa je resničnih dosežkov, ki jih lahko otipamo, malo.
AG: – Morda. Bomo videli.
V: – Nimamo težav na backendu… Morda bi te težave pustili na frontendu? Zakaj se sploh spuščati tja?
AG: – Moramo imeti ekipo frontend razvijalcev.
Malo reklame 🙂
Hvala što ostajete s nama. Da li vam se sviđaju naši članci? Želite li videti više zanimljivih materijala? Podržite nas tako što ćete naručiti ili preporučiti prijateljima, , jedinstveni ekvivalent entry-level servera koji smo stvorili za vas: (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd je dvostruko jeftiniji u Equinix Tier IV data centru u Amsterdamu? Only with us in the Netherlands! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — from $99! Read about how
Izvor: habr.com
