Meetup Go w Kijowie, maj 2018:
Prowadzący: – Cześć wszystkim! Dziękuję, że się zebraliście! Dziś mamy dwóch oficjalnych prelegentów – Ljosza i Wanię. Będzie jeszcze dwóch, jeśli czas nam na to pozwoli. Pierwszy prelegent to Aleksiej Graczow, który opowie o GopherJS.
Aleksiej Graczow (dalej – AG): – Jestem programistą Go i piszę usługi internetowe w Go. Czasem muszę zmierzyć się z front-endem, czasem wkraczałem tam rękami. Chcę opowiedzieć o swoim doświadczeniu i badaniach Go na froncie.
Legenda jest taka: najpierw porozmawiamy, dlaczego chcemy uruchomić Go na frontendzie, a potem omówimy, jak to można zrobić. Są dwie drogi – Web Assembly i GopherJS. Zobaczymy, w jakim stanie znajdują się te rozwiązania i co można z nimi zrobić.
Co jest nie tak z frontendem?
Wszyscy się zgadzają, że z front-endem wszystko jest w porządku?
Mało testów? Wolna kompilacja? Ekosystem? Dobrze.
Jeśli chodzi o front-end, podoba mi się cytat jednego z deweloperów front-endowych w jego książce:
W JavaScript nie ma systemu typów. Teraz wymienię problemy, z którymi się zmagałem w trakcie swojej pracy, oraz wyjaśnię, jak je rozwiązano.
System typów w JavaScript właściwie trudno nazwać systemem typów – są tam łańcuchy, które oznaczają typ obiektu, ale tak naprawdę nie mają z typami nic wspólnego. Ten problem został rozwiązany w TypeScript (rozszerzenie JavaScript) i Flow (statyczny checker typów w JavaScript). Właściwie front-end już dawno dotarł do rozwiązania problemu słabego systemu typów w JavaScript.
Standardowej biblioteki w przeglądarkach właściwie nie ma – są jakieś wbudowane obiekty i «magiczne» funkcje w przeglądarkach. Ale w JavaScript jako takowego standardowej biblioteki brak. Ten problem już raz rozwiązano w jQuery (wszyscy używali jQuery ze wszystkimi prototypami, helperami, funkcjami, które są potrzebne do pracy). Teraz wszyscy używają Lodash:
Callback hell. Myślę, że wszyscy widzieli kod w JavaScript około 5 lat temu, który wyglądał jak «makaron» z niewiarygodnie skomplikowanym splątaniem callbacków. Teraz ten problem został rozwiązany (z wydaniem ES-15 lub ES-16), dodano do JavaScript obietnice (promises) i wszystkim na chwilę stało się łatwiej.
Dopóki nie pojawił się Promice hell… Nie wiem, jak przemysł front-endowy to robi, ale wciąż zapędzają się w jakieś dziwne zakamarki. Udało im się również zrobić hell z «promisów». Potem postanowili rozwiązać ten problem, dodając nowy prymityw – async/await:
Problem z asynchronicznością została rozwiązana. Async/await to dość popularny mechanizm w różnych językach. W Pythonie i w innych językach istnieje takie podejście – jest ono wystarczająco dobre. Problem został rozwiązany.
Jaka problem nie został rozwiązany? Rosnąca w geometrycznej progresji złożoność frameworków, złożoność ekosystemu i samego oprogramowania.
- Składnia JavaScript jest nieco dziwna. Wszyscy znamy problemy z dodawaniem tablic i obiektów oraz inne ciekawe sytuacje.
- JavaScript to język wieloparadygmatowy. Obecnie jest to szczególnie istotny system, gdy ekosystem jest bardzo duży:
- wszyscy piszą w różnych stylach – niektórzy piszą strukturowo, inni funkcjonalnie, różni deweloperzy piszą na różne sposoby;
- z różnych pakietów (packages) pochodzi różne paradygmaty, gdy używasz różnych pakietów;
- jest bardzo dużo "zabawy" z programowaniem funkcyjnym w JavaScript – pojawiła się biblioteka Ramda i teraz nikt nie potrafi czytać programów napisanych w tej bibliotece.
- To wszystko wnosi ogromny wpływ na ekosystem, który rozrósł się w niewiarygodny sposób. Pakiety nie są ze sobą kompatybilne: niektórzy używają obietnic, inni – async/await, jeszcze inni – callbacków. I piszą w różnych paradygmatach!
- To prowadzi do tego, że projekt jest trudny do utrzymania. Trudno znaleźć błąd, jeśli nie możesz przeczytać kodu.
Czym jest Web Assembly?
Dzielni chłopcy z Mozilla Foundation i kilku innych firm wymyślili coś takiego jak Web Assembly. Czym to jest?
- To wbudowana w przeglądarkę maszyna wirtualna, która obsługuje format binarny.
- Programy binarne trafiają tam, są wykonywane praktycznie natywnie, co oznacza, że przeglądarka nie musi za każdym razem analizować całego "spaghetti" kodu JavaScript.
- Wszystkie przeglądarki ogłosiły wsparcie.
- Ponieważ to jest kod bajtowy, można napisać kompilator do dowolnego języka.
- Cztery główne przeglądarki już dostarczają wsparcie dla Web Assembly.
- Wkrótce oczekujemy natywnego wsparcia w Go. Taka nowa architektura już została dodana: GOARCH=wasm GOOS=js (wkrótce). Na razie, jak rozumiem, nie jest to funkcjonalne, jednak istnieje zapowiedź, że na pewno będzie to w Go.
Co teraz robić? GopherJS
Póki nie mamy wsparcia dla Web Assembly, istnieje taki transpiler jak GopherJS.
- Kod w Go jest transpilanowany do "czystego" JavaScript.
- Uruchamia się we wszystkich przeglądarkach – nie ma tam nowych funkcji, które są obsługiwane tylko przez nowoczesne przeglądarki (to Vanilla JS, który działa na wszystkim).
- Obsługiwane jest prawie wszystko, co jest w Go, w tym goroutines i kanały… – wszystko, co tak uwielbiamy i znamy.
- Prawie cała standardowa biblioteka jest wspierana, z wyjątkiem tych pakietów, które nie mają sensu wspierać w przeglądarce: syscall, interakcje sieciowe (jest klient net/http, ale nie ma serwera, a klient jest emulowany przez XMLHttpRequest). Generalnie cała standardowa biblioteka jest dostępna – oto ona w przeglądarce, oto stdlib Go, którą kochamy.
- Cała ekosystem pakietu w Go, wszystkie zewnętrzne rozwiązania (szablony itp.) można skompilować za pomocą GopherJS i uruchomić w przeglądarce.
Zainstalowanie GopherJS jest bardzo łatwe – to zwykły pakiet Go. Wykonujemy go get, a mamy komendę GopherJS, aby zbudować aplikację:
Oto taki mały hello world…
…Zwykły program Go, zwykły pakiet fmt standardowej biblioteki oraz Binding Js, aby uzyskać dostęp do interfejsu API przeglądarki. Println w rezultacie zostanie przekształcone w console log, a przeglądarka wyświetli „Hello gophers”! Tak prosto: wykonujemy GopherJS build – uruchamiamy w przeglądarce – wszystko działa!
Co jest obecnie dostępne? Bindings
Są bindy do wszystkich popularnych frameworków js:
- JQuery;
- Angular.js;
- D3.js do tworzenia wykresów i pracy z dużymi danymi;
- React.js;
- VueJS;
- nawet jest wsparcie dla Electron (więc już teraz możemy pisać aplikacje desktopowe na 'Electron');
- i co najdziwniejsze – to WebGL (możemy tworzyć aplikacje półwymiarowe, w tym gry z grafiką 3D, muzyką i wszystkimi bajerami);
- i naprawdę wiele innych bindów do wszystkich popularnych frameworków i bibliotek javascript.
Framework
- Istnieje już opracowany specjalnie dla GopherJS framework webowy – Vecty. To pełnoprawny odpowiednik React.js, ale zaprojektowany na Go, z specyfiką GopherJS.
- Są też silniki gier (niespodziewanie!). Znalazłem dwa najpopularniejsze:
- Engo;
- Ebiten.
Pokażę parę przykładów, jak to wygląda i co już teraz można napisać w Go:
Lub taka wersja (3D-shooter nie znalazłem, ale być może istnieje):
Co proponuję?
Obecnie przemysł frontendu znajduje się w takim stanie, że wszystkie języki, które do tej pory cierpiały z powodu JavaScriptu, rzucą się w tę stronę. Teraz wszystkie będą kompilować się do 'Web Assembly'. Co potrzebujemy, aby zająć tam godne miejsce jako 'gophers'?
W Go tradycyjnie postrzega się jako język programowania systemowego i praktycznie nie istnieją biblioteki do pracy z interfejsem użytkownika. Coś tam jest, ale jest to częściowo porzucone i częściowo niefunkcjonalne.
I oto – świetna okazja, aby stworzyć biblioteki UI w Go, które będą działały na GopherJS! Można wreszcie napisać własny framework! Nadszedł czas, aby stworzyć framework, który będzie jednym z pierwszych i zdobędzie wczesną adaptację, a Ty staniesz się gwiazdą (jeśli to będzie dobry framework).
Można zaadoptować mnóstwo różnych pakietów, które już istnieją w ekosystemie Go, do specyfiki przeglądarki (na przykład silnika szablonów). One i tak już działają, można stworzyć wygodne opakowania, aby można było łatwo renderować treści bezpośrednio w przeglądarce. Dodatkowo można stworzyć na przykład serwis, który potrafi renderować to samo na serwerze i na frontendzie, używając tego samego kodu – wszystko zgodnie z tym, co lubią deweloperzy frontendowi (tylko teraz w Go).
Można napisać grę! Just for fun…
To wszystko z mojej strony.
Pytania
Pytanie (dalej – P): – Piszę w Go czy w Js?
AG: – Piszesz w Go – rutyny, kanały, struktury, osadzanie – wszystko... Zapisujesz się na event, przekazujesz tam funkcję.
P: – Czyli piszę w 'czystym' Js?
AG: – Nie, piszesz jakby w Go i łączysz się z API przeglądarki (API się nie zmieniło). Możesz napisać swoje opakowania, aby wiadomości trafiały do kanału – to nie jest trudne.
P: – A co z mobilnymi aplikacjami?
AG: – Na pewno widziałem: są bindy dla patcha Cordova, który uruchamia Js. W React Native – nie wiem; może są, a może nie (nie interesowałem się tym zbytnio). Silnik gier N-go obsługuje także aplikacje mobilne – zarówno iOS, jak i Android.
P: – Pytanie dotyczące Web Assembly. Zajmuje coraz więcej miejsca, mimo kompresji, „zipowania”... Czy w ten sposób nie zrujnujemy jeszcze bardziej świata frontendowego?
AG: – Web Assembly to format binarny i z definicji nie może być większy w finalnym wydaniu od tekstu... Ciągnie Cię do runtime, ale to to samo, co ściągnięcie standardowej biblioteki Javascript, gdy jej nie ma, dlatego używamy czegoś takiego jak Lodash. Nie wiem, ile zajmuje Lodash.
P: – Zdecydowanie mniej niż runtime…
AG: – Na 'czystym' Javascript?
P: – Tak. Przecież go kompresujemy przed wysłaniem...
AG: – Ale to jest tekst… Ogólnie rzecz biorąc, megabajt to jakby dużo, ale to wszystko (masz cały runtime). Następnie piszesz swoją logikę biznesową, która zwiększy twój binary o 1%. Na razie nie widzę, żeby to zabiło frontend. Zwłaszcza, że Web Assembly będzie działać szybciej niż Javascript z oczywistego powodu – nie trzeba go analizować.
P: – To wciąż kontrowersyjny temat… Nie ma jeszcze jakiejś wzorcowej implementacji „Wasma” (Web Assembly), żeby można było jednoznacznie to ocenić. Koncepcyjnie – tak: wszyscy rozumiemy, że binary powinno być szybsze, ale obecna implementacja V8 jest bardzo efektywna.
AG: – Tak.
P: – Kompilacja tam naprawdę działa bardzo dobrze i nie ma pewności, że będzie duża przewaga.
AG: – Web Assembly również robią duzi gracze.
P: – Na razie, wydaje mi się, że trudno ocenić Web Assembly. Już ile lat się o tym rozmawia, a rzeczywistych osiągnięć, które można dotknąć, jest niewiele.
AG: – Możliwe. Będziemy obserwować.
P: – Nie mamy problemów na backendzie… Może lepiej zostawić te problemy na frontendzie? Po co tam w to wnikać?
AG: – Musimy trzymać zespół frontendowców.
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
