Алексей Грачев: Go Frontend

Kyiv Go Meetup май 2018 г.:

Модератор: - Здравейте всички! Благодаря ви, че сте тук! Днес имаме двама официални говорители - Льоша и Ваня. Ще има още две, ако имаме достатъчно време. Първият лектор е Алексей Грачев, той ще ни разкаже за GopherJS.

Алексей Грачев (по-нататък – АГ): – Аз съм разработчик на Go и пиша уеб услуги на Go. Понякога трябва да се справите с интерфейса, понякога трябва да влезете в него ръчно. Искам да говоря за моя опит и проучване на Go в интерфейса.

Легендата е следната: първо ще поговорим защо искаме да стартираме Go във фронтенда, след това ще поговорим как може да стане това. Има два начина - Web Assembly и GopherJS. Нека да видим какво е състоянието на тези решения и какво може да се направи.

Какво не е наред с интерфейса?

Всички ли са съгласни, че всичко е наред с интерфейса?

Няма ли достатъчно тестове? Бавно изграждане? Екосистема? Глоба.

По отношение на интерфейса, харесвам цитата, който един от разработчиците на интерфейса каза в книгата си:

Javascript няма система от типове. Сега ще назова проблемите, които срещнах в хода на работата си и ще обясня как се решават.

Типовата система като цяло трудно може да се нарече типова система в Javasript - има редове, които показват типа на обекта, но всъщност това няма нищо общо с типовете. Този проблем е решен в TypeScript (добавка към Javasript) и Flow (проверка на статичен тип в Javascript). Всъщност интерфейсът вече е достигнал точката на решаване на проблема с лош тип система в Javascript.

В браузъра няма стандартна библиотека като такава - има някои вградени обекти и „магически“ функции в браузърите. Но в Javascript няма стандартна библиотека като такава. Този проблем вече беше решен веднъж от jQuery (всички използваха jQuery с всички прототипи, помощници, функции, които бяха необходими за работа). Сега всички използват Lodash:

Обратно обаждане по дяволите. Мисля, че всеки видя Javascript код преди около 5 години и изглеждаше като „юфка“ от невероятна сложност от обратни извиквания. Сега този проблем е решен (с пускането на ES-15 или ES-16), обещанията са добавени към Javascript и всеки може да диша по-лесно за известно време.

Докато не дойде адът на Promice... Не знам как се справя front-end индустрията, но винаги се карат в някаква странна джунгла. Успяхме и да направим адски много обещания. След това решихме този проблем, като добавихме нов примитив - async/await:

Проблемът с асинхронността е решен. Async/await е доста популярен примитив на различни езици. Python и други имат този подход - доста е добър. Проблема решен.

Какъв проблем не е решен? Експоненциално нарастващата сложност на рамките, сложността на екосистемата и самите програми.

• Синтаксисът на Javascript е малко странен. Всички знаем проблемите с добавянето на масив и обект и други шеги.
• Javascript е мулти-парадигма. Това е особено належаща система сега, когато екосистемата е много голяма:
  • всеки пише в различни стилове - някои пишат структурно, други пишат функционално, различните разработчици пишат по различни начини;
  • от различни пакети, различни парадигми, когато използвате различни пакети;
  • има много „забавление“ с функционалното програмиране в Javasript - библиотеката 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 има, включително goroutines и канали... всичко, което обичаме и знаем толкова много.
• Поддържа се почти цялата стандартна библиотека, с изключение на онези пакети, които няма смисъл да се поддържат в браузъра: syscall, нетни взаимодействия (има net/http клиент, но няма сървър и клиентът се емулира чрез XMLHttpRequest). Общо взето цялата стандартна библиотека е налична - ето я в браузъра, ето stdlib на Go, който обичаме.
• Цялата пакетна екосистема в Go, всички решения на трети страни (шаблони и т.н.) могат да бъдат компилирани с помощта на GopherJS и стартирани в браузъра.

GopherJS е много лесен за получаване - това е просто обикновен Go пакет. Отиваме да вземем и имаме команда GopherJS за изграждане на приложението:

Това е толкова малък здравей свят...

...Обикновена програма Go, стандартен fmt пакет за библиотека и Binding Js за достигане до API на браузъра. Println в крайна сметка ще бъде преобразуван в конзолен журнал и браузърът ще изпише „Hello gophers“! Толкова е просто: ние изграждаме GopherJS – стартираме го в браузъра – всичко работи!

Какво имаш в момента? Подвързии

Има обвързвания за всички популярни js рамки:

• JQuery;
• Angular.js;
• D3.js за чертане и работа с големи данни;
• React.js;
• VueJS;
• има дори поддръжка за Electron (тоест вече можем да пишем настолни приложения на Electron);
• и най-смешното нещо е WebGL (можем да правим изцяло графични приложения, включително игри с 3D графика, музика и всички екстри);
• и много други обвързвания към всички популярни javascript рамки и библиотеки.

Рамка

1. Вече има уеб рамка, разработена специално за GopherJS - Vecty. Това е пълноценен аналог на React.js, но само разработен в Go, със спецификата на GopherJS.
2. Има чанти за игра (изненада!). Намерих двата най-популярни:
   • Engo;
   • Ебитен.

Ще ви покажа няколко примера за това как изглежда и какво вече можете да пишете в Go:

Или тази опция (не можах да намеря 3D шутър, но може би съществува):

Какво предлагам?

Сега индустрията на предния край е в такова състояние, че всички езици, които преди това плакаха от Javascript, ще се втурнат там. Сега всичко ще бъде компилирано в „Web Assemblies“. Какво ни трябва, за да заемем полагащото ни се място там като гофери?

Go традиционно приема, че е език за системно програмиране и практически няма библиотеки за работа с потребителския интерфейс. Има нещо, но е наполовина изоставено, наполовина нефункционално.

И сега е добър шанс да направите UI библиотеки в Go, които да работят на GopherJS! Най-накрая можете да напишете своя собствена рамка! Това е моментът, когато можете да напишете рамка и тя ще бъде една от първите и ще бъде възприета ранно, и ще бъдете звезда (ако е добра рамка).

Можете да адаптирате много различни пакети, които вече са в екосистемата Go към спецификата на браузъра (например Template engine). Те вече ще работят, можете да направите удобни обвързвания, така че лесно да изобразявате съдържанието директно в браузъра. Освен това можете да създадете, например, услуга, която може да рендира едно и също нещо на сървъра и на предния край, използвайки един и същ код – всичко, което харесват разработчиците на предния край (само сега в Go).

Можете да напишете игра! Просто за забавление…

Това е всичко, което исках да кажа.

Въпроси

Въпрос (наричан по-долу Q): – Да пиша на Go или Js?

AG: – Пишеш рутини, канали, структури, вграждане – всичко в Go... Абонираш се за събитие, предаваш функция там.

AT: – Значи пиша с „голи“ Js?

AG: – Не, пишете като в Go и се свързвате с API на браузъра (API не е променен). Можете да напишете свои собствени обвързвания, така че съобщенията да се изпращат до канала - не е трудно.

AT: – Ами мобилното?

AG: – Определено видях: има обвързвания за кордова корекция, която Js изпълнява. В React Native - не знам; може би има, може би не (не се интересувах особено). Енджинът на играта N-go поддържа и двете мобилни приложения - както iOS, така и Android.

AT: – Въпрос относно Web Assembly. Все повече и повече място се заема, въпреки компресията и „ципването“... Няма ли да убием фронтенд света по този начин още повече?

AG: – Web Assembly е двоичен формат, а двоичният по подразбиране не може да бъде във финалната версия повече от текст... Вие сте привлечени от времето за изпълнение, но това е същото като да изтеглите стандартната библиотека на Javascript, когато я няма, така че ние използвайте малко Lodash. Не знам колко взема Lodash.

AT: – Очевидно по-малко от времето за изпълнение...

AG: – В „чист“ Javascript?

AT: - да Ние го компресираме, преди да го изпратим...

AG: – Но това е текст... Като цяло един мегабайт изглежда много, но това е всичко (имате цялото време за изпълнение). След това пишете своя собствена бизнес логика, която ще увеличи двоичния ви файл с 1%. Засега не виждам това да убива интерфейса. Освен това Web Assembly ще работи по-бързо от Javascript по очевидната причина – не е необходимо да се анализира.

AT: – Това все още е спорен момент... Все още няма референтна реализация на “Vasma” (Web Assembly), за да може да се прецени еднозначно. Концептуално, да: всички разбираме, че бинарният код трябва да бъде по-бърз, но сегашното внедряване на същия V8 е много ефективно.

AG: - Да.

AT: – Компилацията там работи наистина много готино и не е факт, че ще има голямо предимство.

AG: – Web Assembly също се прави от големи момчета.

AT: – Струва ми се, че все още е трудно да се прецени Web Assembly. Разговори се водят от много години, но малко са реалните постижения, които могат да се усетят.

AG: - Може би. Ще видим.

AT: – Нямаме проблеми на бекенда... Може би трябва да оставим тези проблеми на фронтенда? Защо да ходя там?

AG: – Трябва да поддържаме персонал от работници на първа линия.

Малко реклами 🙂

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

Източник: www.habr.com