Киев Go Meetup Май 2018:
Водещ: – Здравейте на всички! Благодаря, че сте тук! Днес имаме двама официални лектори – Льоша и Ваня. Ще има и още двама, ако ни стигне времето. Първият лектор – Алексей Грачев, той ще ни разкаже за GopherJS.
Алексей Грачев (по-нататък – АГ): – Аз съм Go-разработчик и пиша уеб услуги на Go. Понякога се налага да се сблъсквам с фронтенда, понякога трябва да се заровя там с ръце. Искам да споделя опита и изследванията си за Go на фронтенда.
Легендата е такава: първо ще поговорим защо искаме да използваме Go на фронтенда, после ще обсъдим как може да се направи това. Има два пътя – Web Assembly и GopherJS. Нека да видим в какво състояние са тези решения и какво можем да правим.
Какво не е наред с фронтенда?
Всички ли са съгласни, че всичко е наред с фронтенда?
Недостатъчно тестове? Бавна компилация? Екосистема? Добре.
По отношение на фронтенда, ми харесва цитата на един от фронтенд разработчиците в неговата книга:
В Javascript няма система от типове. Сега ще назова проблемите, с които съм се сблъсквал в хода на своята работа и ще обясня как ги решаваме.
Системата от типове е трудно да се нарече система от типове в Javascript – там има низове, които обозначават типа на обекта, но всъщност това не е свързано с типовете. Тази проблема е решена в TypeScript (разширение на Javascript) и Flow (статичен проверител на типове в Javascript). Всъщност, фронтендът вече е достигнал решение на проблема с лошата система от типове в Javascript.
Стандартната библиотека в браузера като цяло липсва – има някакви вградени обекти и "магически" функции в браузерите. Но в Javascript основната библиотека отсъства. Тази проблема вече беше решена преди време с jQuery (всички използваха jQuery с всички прототипи, помощни функции, необходими за работа). Сега всички използват Lodash:
Callback hell. Мисля, че всички сте виждали код на Javascript преди около 5 години, и той приличаше на "лапша" от невероятна плетеница от колбекове. Сега този проблем е решен (с излизането на ES-15 или ES-16), добавиха в Javascript промиси (promises) и на всички им стана малко по-лесно.
Докато не дойде Promice hell… Не знам как фронтенд индустрията упражнява това, но те всеки път си попада в странни задънени улици. Успяха и на "промисите" да направят hell. После решиха този проблем, добавяйки нов примитив – async/await:
Проблемата с асинхронността е решена. Async/await е достатъчно популярна концепция в различни езици. И в „Python“, и в други езици съществува такъв подход – той е доста добър. Проблемът е решен.
Коя проблема не е решена? Нарастващата геометрична сложност на фреймворците, сложността на екосистемата и самите програми.
- Синтаксисът на Javascript е малко странен. Всички знаем проблемите с обединяването на масиви и обекти и други забавни ситуации.
- Javascript е мулти-парадигмен. В момента това е особено актуална система, когато екосистемата е много голяма:
- всички пишат в различни стилове – някои пишат структурно, други функционално, различни разработчици пишат по различен начин;
- от различни пакети (packages) идват различни парадигми, когато използвате различни пакети;
- има много „забавления“ с функционалното програмиране в Javascript – библиотеката rambda е появила и сега никой не може да чете програми, написани с нея.
- Всичко това създава голямо влияние в екосистемата, и тя е нараснала невероятно. Пакетите не са съвместими помежду си: някои използват промиси, други – async/await, а трети – колбекове. Пък и се пише в различни парадигми!
- Това води до трудности в поддържането на проекта. Трудно е да се намери бъг, ако не можеш да прочетеш кода.
Какво е Web Assembly?
Смелите хора от Mozilla Foundation и редица други компании измислиха нещо, наречено Web Assembly. Какво е това?
- Това е вградена в браузъра виртуална машина, която поддържа бинарен формат.
- Бинарните програми влизат там, извършват се практически нативно, т.е. браузерът не трябва всеки път да парсира цялата „лапша“ от javascript код.
- Всички браузъри обявиха за поддръжка.
- Тъй като това е байт-код, може да се напише компилатор за всеки език.
- Четирите основни браузъра вече идват с поддръжка за Web Assembly.
- Скоро очакваме нативна поддръжка в Go. Такава нова архитектура вече е добавена: GOARCH=wasm GOOS=js (скоро). В момента, доколкото разбирам, тя не е функционална, но има заявление, че определено ще бъде в 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 в крайна сметка ще бъде преобразуван в лог на конзолата и браузърът ще напише "Hello gophers"! Толкова е просто: правим GopherJS build – стартираме в браузъра – всичко работи!
Какво имаме в момента? Привързвания
Има привързвания към всички популярни js фреймуъркове:
- JQuery;
- Angular.js;
- D3.js за изграждане на графики и работа с големи данни;
- React.js;
- VueJS;
- дори има поддръжка за Electron (тъй като вече можем да пишем десктопни приложения на "Електрон");
- и най-забавното – това е WebGL (можем да правим пълно графични приложения, включително игри с 3D графика, музика и всички прелести);
- и много други привързвания към всички популярни javascript фреймуъркове и библиотеки.
Фреймуърк
- Има вече разработен специално за GopherJS уеб фреймуърк – Vecty. Това е пълноценен аналог на React.js, но само разработен на Go, със спецификата на GopherJS.
- Има игрови библиотеки (изненадващо!). Намерих два от най-популярните:
- Engo;
- Ebiten.
Ще демонстрирам няколко примера, как изглежда и какво вече можем да напишем на Go:
Или такъв вариант (не намерих 3D шутър, но може би има):
Какво предлагам?
В момента индустрията на фронтенда е в такова състояние, че всички езици, които преди плакаха от Javascript, сега ще се нахвърлят там. Сега всички ще се компилират в "WebAssembly". Какво ни трябва, за да заемем достойно място там като "гофери"?
В Go традиционно считается, что это – системный язык программирования, и практически нет библиотек для работы с пользовательскими интерфейсами. Что-то есть, но это наполовину заброшено и наполовину не функционирует.
И вот – отличный шанс создать UI-библиотеки на Go, которые будут запускаться на GopherJS! Можно, наконец, написать свой фреймворк! Наступило то время, когда можно написать фреймворк, который станет одним из первых и получит раннюю адаптацию, и вы станете звездой (если это будет хороший фреймворк).
Можно адаптировать множество различных пакетов, которые уже существуют в экосистеме Go, к специфике браузера (например, шаблонизаторы). Они уже работают, и можно создать удобные обертки, чтобы легко рендерить контент прямо в браузере. Плюс, можно создать, например, сервис, который будет рендерить одно и то же на сервере и на фронтенде, используя один и тот же код – всё как любят фронтенд-разработчики (только теперь на Go).
Можно написать игру! Просто для удовольствия…
У меня всё.
Въпроси
Вопрос (далее – В): – Я пишу на Go или на JS?
АГ: – Ты пишешь на Go – рутины, каналы, структуры, внедрение – всё это… Ты подписываешься на событие, передаёшь туда функцию.
В: – То есть я пишу на «голом» JS?
АГ: – Нет, ты пишешь как бы на Go и подключаешься к API браузера (API при этом не изменился). Можешь написать свои обертки, чтобы в канал приходили сообщения – это же несложно.
В: – Что насчёт мобильных приложений?
АГ: – Я точно видел: есть биндинги для патча Cordova, которые запускаются с помощью JS. В React Native – не знаю; может, есть, а может, нет (не особо интересовался). Игровой движок N-go поддерживает и мобильные приложения – как iOS, так и Android.
В: – Вопрос по Web Assembly. Местоположение занимает всё больше, несмотря на сжатие, «зазипованность»… Не убьём ли мы таким образом мир фронтенда ещё больше?
АГ: – Web Assembly – это бинарный формат, и бинарный, по умолчанию, не может быть в финальном релизе больше, чем текст… У вас проблемы с модулем времени выполнения, но это то же самое, что стараться подключить стандартную библиотеку JavaScript, когда её нет, поэтому мы используем какой-нибудь Lodash. Не знаю, сколько занимает Lodash.
В: – Очевидно, меньше, чем модуль времени выполнения…
АГ: – На «чистом» JavaScript?
В: – Да. Мы же его сжимаем перед тем, как отправлять…
АГ: – Но това е текст… Общо взето, мегабайтът изглежда много, но това е всичко (имаш целия runtime). След това пишеш своята бизнес логика, която ще увеличи binary-то с 1%. Не виждам как това убива фронтенда. Освен това Web Assembly ще работи по-бързо от Javascript по очевидна причина – не трябва да се парсва.
В: – Все още е спорен момент… Все още няма никаква еталонна реализация на „Васма“ (Web Assembly), за да можем недвусмислено да съдим. Концептуално – да: всички разбираме, че binary-то трябва да е по-бързо, но текущата реализация на V8 е изключително ефективна.
АГ: – Да.
В: – Компилацията там работи наистина много добре и не е факт, че ще има значително предимство.
АГ: – Web Assembly също се разработва от големи компании.
В: – Все още, ми се струва, е трудно да се съди за Web Assembly. Вече колко години се говорят тези неща, а реалните постижения, които можем да докоснем, са малко.
АГ: – Може би. Ще видим.
В: – Нямаме проблеми на бекенда… Може би да оставим тези проблеми на фронтенда? Защо да се намесваме там?
АГ: – Налага се да държим екип от фронтенд разработчици.
Малко реклама 🙂
Благодаря, че оставате с нас. Харесвате ли нашите статии? Искате ли да видите повече интересни материали? Подкрепете ни, като направите поръчка или я препоръчате на познати, , уникален аналог на entry-level сървъри, създаден от нас за Вас: (налични опции с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd два пъти по-евтин в дата-центъра Equinix Tier IV в Амстердам? Само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Четете за това
Източник: habr.com
