Spotkanie Kyiv Go w maju 2018 r.:
Moderator: - Cześć wszystkim! Dziękuję, że tu jesteś! Dziś mamy dwóch oficjalnych prelegentów - Lyosha i Vanya. Jeśli starczy nam czasu, będzie jeszcze dwóch. Pierwszym prelegentem będzie Alexey Grachev, który opowie nam o GopherJS.
Alexey Grachev (dalej - AG): – Jestem programistą Go i piszę usługi sieciowe w Go. Czasem trzeba uporać się z frontendem, czasem trzeba się tam wspiąć uchwytami. Chcę porozmawiać o moim doświadczeniu i badaniach Go na froncie.
Legenda jest taka: najpierw porozmawiamy o tym, dlaczego chcemy uruchomić Go na frontendzie, a potem porozmawiamy o tym, jak możemy to zrobić. Istnieją dwa sposoby - Web Assembly i GopherJS. Zobaczmy, w jakim stanie są te decyzje i co można zrobić.
Co jest nie tak z frontendem?
Wszyscy zgadzają się, że wszystko jest w porządku z frontendem?
Kilka testów? Powolna budowa? ekosystem? Cienki.
Jeśli chodzi o front-end, podoba mi się cytat, który jeden z programistów front-end powiedział w swojej książce:
Javascript nie ma systemu typów. Teraz wymienię problemy, które napotkałem w trakcie mojej pracy i wyjaśnię, jak zostały rozwiązane.
System typów jest ogólnie trudny do nazwania systemem typów w JavaScript - istnieją linie wskazujące typ obiektu, ale w rzeczywistości nie ma to nic wspólnego z typami. Ten problem został rozwiązany w TypeScript (dodatek do JavaScript) i Flow (statyczne sprawdzanie typów w JavaScript). W rzeczywistości frontend posunął się już do rozwiązania problemu złego systemu typów w JavaScript.
W przeglądarce jako takiej nie ma standardowej biblioteki - w przeglądarkach jest kilka wbudowanych obiektów i „magicznych” funkcji. Ale nie mam standardowej biblioteki w JavaScript jako takiej. Ten problem został już rozwiązany przez jQuery (wszyscy używali jQuery ze wszystkimi prototypami, pomocnikami, funkcjami, które musiały działać). Teraz wszyscy używają Lodash:
piekło zwrotne. Myślę, że każdy widział kod JavaScript około 5 lat temu i wyglądał jak „makaron” z niesamowitych zawiłości wywołań zwrotnych. Teraz ten problem został rozwiązany (wraz z wydaniem ES-15 lub ES-16), dodano obietnice do Javascript i przez chwilę wszyscy zaczęli odetchnąć z ulgą.
Dopóki nie nadeszło piekło Promice... Nie wiem jak sobie radzi branża front-endowa, ale zawsze wjeżdżają w jakąś dziwną dżunglę. Udało nam się też zrobić piekło na „obietnicach”. Następnie rozwiązaliśmy ten problem, dodając nowy prymityw - async / await:
Dzięki asynchronizacji problem został rozwiązany. Async/await jest dość popularnym prymitywem w różnych językach. Python i inni mają takie podejście - jest wystarczająco dobre. Problem rozwiązany.
Jaki problem nie został rozwiązany? Wykładniczo rosnąca złożoność frameworków, złożoność ekosystemu i samych programów.
- Składnia Javascript jest trochę dziwna. Wszyscy znamy problemy z dodawaniem tablicy i obiektu oraz inne sztuczki.
- JavaScript jest wieloparadygmatowy. Teraz jest to szczególnie pilny system, gdy ekosystem jest bardzo duży:
- każdy pisze w innym stylu - ktoś pisze strukturalnie, ktoś pisze funkcjonalnie, różni programiści piszą inaczej;
- z różnych pakietów (pakietów) różne paradygmaty, gdy używasz różnych pakietów;
- dużo "zabawy" z programowaniem funkcyjnym w Javascript - pojawiła się biblioteka rambda i teraz nikt nie może czytać programów napisanych w tej bibliotece.
- Wszystko to ma duży wpływ na ekosystem, który niesamowicie się rozrósł. Pakiety są ze sobą niekompatybilne: niektóre są na obietnicach, niektóre na async/oczekiwaniu, niektóre na wywołaniach zwrotnych. Piszą też w różnych paradygmatach!
- Utrudnia to utrzymanie projektu. Trudno jest znaleźć błąd, jeśli nie możesz odczytać kodu.
Co to jest montaż sieciowy?
Odważni faceci z Fundacji Mozilla i wielu innych firm wymyślili coś takiego jak Web Assembly. Co to jest?
- Jest to maszyna wirtualna wbudowana w przeglądarkę obsługująca format binarny.
- Programy binarne docierają, są wykonywane niemal natywnie, czyli przeglądarka nie musi za każdym razem analizować wszystkich „makaronów” kodu javascript.
- Wszystkie przeglądarki zadeklarowały wsparcie.
- Ponieważ jest to kod bajtowy, możesz napisać kompilator dla dowolnego języka.
- Cztery główne przeglądarki są już dostarczane z obsługą Web Assembly.
- Wkrótce spodziewamy się wsparcia natywnego w Go. Ta nowa architektura została już dodana: GOARCH=wasm GOOS=js (wkrótce). Póki co, jak rozumiem, nie jest funkcjonalny, ale jest stwierdzenie, że w Go na pewno będzie.
Co zrobić teraz? GopherJS
Chociaż nie mamy wsparcia dla Web Assembly, istnieje transpiler, taki jak GopherJS.
- Kod Go jest transpilowany do „czystego” JavaScript.
- Działa we wszystkich przeglądarkach - nie ma nowych funkcji, które są obsługiwane tylko przez nowoczesne przeglądarki (jest to Vanilla JS, który działa na wszystkim).
- Istnieje wsparcie dla prawie wszystkiego, co jest w Go, w tym gorutyn i kanałów… - wszystkiego, co tak bardzo kochamy i wiemy.
- Obsługiwana jest prawie cała biblioteka standardowa, z wyjątkiem tych pakietów, których obsługa w przeglądarce nie ma sensu: syscall, interakcje sieciowe (jest klient net / http, ale nie ma serwera, a klient jest emulowany przez XMLHttpRequest) . Ogólnie rzecz biorąc, dostępna jest cała standardowa biblioteka - tutaj jest w przeglądarce, tutaj jest Go stdlib, który kochamy.
- Cały ekosystem pakietów w Go, wszystkie rozwiązania firm trzecich (szablony itp.) można skompilować za pomocą GopherJS i uruchomić w przeglądarce.
Zdobycie GopherJS jest bardzo proste - to zwykły pakiet Go. Robimy go get i mamy polecenie GopherJS do zbudowania aplikacji:
Oto taki mały hello świat...
...Zwykły program Go, zwykły pakiet fmt ze standardową biblioteką i Binding Js, aby dotrzeć do API przeglądarki. Println ostatecznie zostanie przekonwertowany na dziennik konsoli, a przeglądarka napisze „Cześć świstaki”! To takie proste: robimy build GopherJS - uruchamiamy go w przeglądarce - wszystko działa!
Co jest w tej chwili? Wiązania
Istnieją powiązania dla wszystkich popularnych frameworków js:
- jquery;
- Angular.js
- D3.js do kreślenia i pracy z dużymi zbiorami danych;
- React.js
- VueJS;
- jest nawet wsparcie dla Electron (czyli możemy już pisać aplikacje desktopowe na Electron);
- a najzabawniejsze jest WebGL (możemy tworzyć aplikacje w pełni graficzne, w tym gry z grafiką 3D, muzyką i wszystkimi dodatkami);
- oraz wiele innych powiązań ze wszystkimi popularnymi frameworkami i bibliotekami javascript.
Framework
- Istnieje już framework sieciowy opracowany specjalnie dla GopherJS - Vecty. Jest to pełnoprawny analog React.js, ale rozwijany tylko w Go, ze specyfiką GopherJS.
- Są torby na dziczyznę (nagle!). Znalazłem dwa najpopularniejsze:
- engo;
- Ebiten.
Pokażę kilka przykładów jak to wygląda i co już można napisać w Go:
Lub ta opcja (nie znalazłem strzelanki 3D, ale może istnieje):
Co sugeruję?
Teraz branża front-end jest w takim stanie, że pędzą tam wszystkie języki, które wcześniej płakały z Javascript. Teraz wszystko zostanie skompilowane do „Zestawów sieciowych”. Czego potrzebujemy, aby zająć tam godne miejsce jako „świsty”?
W Go tradycyjnie odeszło, że jest to systemowy język programowania i praktycznie nie ma bibliotek do pracy z interfejsem użytkownika. Coś jest, ale w połowie porzucone, w połowie niefunkcjonalne.
A teraz - dobra okazja, aby stworzyć biblioteki UI w Go, które będą działać na GopherJS! Możesz w końcu napisać swój własny framework! Nadszedł czas, kiedy będziesz mógł napisać framework, który będzie jednym z pierwszych i wcześnie przyjęty, a ty będziesz gwiazdą (jeśli to dobry framework).
Możesz dostosować wiele różnych pakietów, które już istnieją w ekosystemie Go do specyfiki przeglądarki (na przykład silnik szablonów). Będą już działać, możesz zrobić wygodne wiązania, dzięki czemu możesz łatwo renderować zawartość bezpośrednio w przeglądarce. Dodatkowo możesz stworzyć na przykład usługę, która może renderować to samo na serwerze i na front-endzie, używając tego samego kodu - wszystko to, co lubią programiści front-end (tylko teraz w Go).
Możesz napisać grę! Dla żartu…
To wszystko.
pytania
Pytanie (zwane dalej Q): – Piszę w Go czy Js?
AG: – Piszesz procedury, kanały, struktury, osadzanie – wszystko w Go… Subskrybujesz wydarzenie, przekazujesz tam funkcję.
W: - To znaczy piszę na "nagich" Js?
AG: - Nie, piszesz jak w Go i łączysz się z API przeglądarki (API się nie zmieniło). Możesz napisać własne powiązania, aby wiadomości przychodziły na kanał - to nie jest trudne.
W: - A co z telefonem komórkowym?
AG: - Widziałem na pewno: są segregatory do łaty Cordova, którą wypuszcza Js. W React Native nie wiem; może jest, może nie (nieszczególnie zainteresowany). Silnik gry N-go obsługuje obie aplikacje mobilne – zarówno iOs, jak i Android.
W: – Pytanie o Web Assembly. Coraz więcej miejsc jest zajętych, pomimo zwięzłości, „zamknięcia”… Czy nie zabijemy w ten sposób świata frontendu jeszcze bardziej?
AG: - Web Assembly jest formatem binarnym, a domyślny plik binarny nie może być większy niż tekst w ostatecznej wersji ... Środowisko wykonawcze jest pobierane, ale jest to to samo, co pobieranie standardowej biblioteki JavaScript, gdy jej tam nie ma, więc my użyj trochę Lodasha. Nie wiem, jak długo trwa Lodash.
W: - Oczywiście mniej niż czas pracy ...
AG: - Na „czystym” JavaScript?
W: - Tak. Kompresujemy go przed wysłaniem...
AG: - Ale to jest tekst... Ogólnie rzecz biorąc, megabajt to jak dużo, ale to wszystko (masz cały czas działania). Następnie piszesz własną logikę biznesową, która zwiększy Twój plik binarny o 1%. Jak dotąd nie widzę, żeby to zabijało frontend. Co więcej, Web Assembly będzie działać szybciej niż Javascript z oczywistego powodu - nie trzeba go analizować.
W: - Póki co kontrowersyjny punkt... Nadal nie ma referencyjnej implementacji "Wasmy" (Web Assembly), aby można było jednoznacznie ocenić. Koncepcyjnie tak: wszyscy rozumiemy, że binarny powinien być szybszy, ale obecna implementacja tego samego V8 jest bardzo wydajna.
AG: - TAk.
W: - Kompilacja tam działa naprawdę bardzo fajnie i nie jest faktem, że będzie duża przewaga.
AG: - Web Assembly jest również tworzone przez dużych facetów.
W: - Jak dotąd wydaje mi się, że nadal trudno oceniać Web Assembly. Od wielu lat toczą się rozmowy, ale realnych osiągnięć, które można odczuć, jest niewiele.
AG: - Może. Zobaczmy.
W: – Nie mamy problemów na backendzie… Może powinniśmy zostawić te problemy na frontendzie? Po co tam iść?
AG: - Musimy zatrzymać kadrę frontlinerów.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com