Kyiv Go Meetup květen 2018:
Moderátor: - Ahoj všichni! Děkujeme, že jste tady! Dnes tu máme dva oficiální řečníky - Lyosha a Vanya. Pokud budeme mít dostatek času, budou další dva. První řečník je Alexey Grachev, poví nám o GopherJS.
Alexey Grachev (dále jen AG): – Jsem vývojář Go a píšu webové služby v Go. Někdy se musíte vypořádat s frontendem, někdy se do něj musíte dostat ručně. Chci mluvit o svých zkušenostech a výzkumu Go na frontendu.
Legenda je tato: nejprve si promluvíme o tom, proč chceme spustit Go na frontendu, a pak si promluvíme o tom, jak to lze udělat. Existují dva způsoby – Web Assembly a GopherJS. Podívejme se, jaký je stav těchto řešení a co lze dělat.
Co je špatného na frontendu?
Souhlasí všichni s tím, že s frontendem je vše v pořádku?
Není dostatek testů? Pomalá stavba? Ekosystém? Pokuta.
Pokud jde o frontend, líbí se mi citát, který řekl jeden z vývojářů frontendu ve své knize:
Javascript nemá typový systém. Nyní pojmenuji problémy, se kterými jsem se při své práci setkal, a vysvětlím, jak se řeší.
Typový systém obecně lze v Javasriptu jen stěží nazvat typovým systémem - existují řádky, které označují typ objektu, ale ve skutečnosti to nemá s typy nic společného. Tento problém je vyřešen v TypeScript (doplněk pro Javasript) a Flow (kontrola statického typu v Javascriptu). Frontend ve skutečnosti již dosáhl bodu, kdy řeší problém špatného typu systému v Javascriptu.
V prohlížeči jako takovém neexistuje žádná standardní knihovna – v prohlížečích jsou některé vestavěné objekty a „magické“ funkce. Ale v Javascriptu žádná standardní knihovna jako taková neexistuje. Tento problém již jednou jQuery řešil (všichni používali jQuery se všemi prototypy, pomocníky, funkcemi, které byly potřeba k práci). Nyní každý používá Lodash:
Zpětné volání do pekla. Myslím, že každý viděl kód Javascript asi před 5 lety a vypadalo to jako „nudle“ neuvěřitelné složitosti zpětných volání. Nyní je tento problém vyřešen (s vydáním ES-15 nebo ES-16), do Javascriptu přibyly přísliby a všem se na chvíli lépe dýchá.
Dokud nepřišlo peklo Promice... Nevím, jak to front-endový průmysl zvládá, ale vždycky se zaženou do nějaké podivné džungle. Podařilo se nám udělat peklo i ze slibů. Pak jsme tento problém vyřešili přidáním nového primitiva - async/await:
Problém s asynchronií je vyřešen. Async/await je poměrně populární primitiv v různých jazycích. Python a další mají tento přístup - je to docela dobré. Problém je vyřešen.
Jaký problém není vyřešen? Exponenciálně rostoucí složitost rámců, složitost ekosystému a samotných programů.
- Syntaxe Javascriptu je trochu zvláštní. Všichni známe problémy s přidáváním pole a objektu a další srandičky.
- Javascript je multiparadigma. Toto je obzvláště naléhavý systém nyní, když je ekosystém velmi rozsáhlý:
- každý píše jiným stylem – někdo píše strukturálně, někdo funkčně, různí vývojáři píší různými způsoby;
- z různých balíčků, různých paradigmat, když používáte různé balíčky;
- s funkcionálním programováním v Javasriptu je spousta „zábavy“ - objevila se knihovna rambda a nyní nikdo nemůže číst programy napsané v této knihovně.
- To vše má velký dopad na ekosystém a neuvěřitelně se rozrostl. Balíčky jsou vzájemně nekompatibilní: některé jsou založeny na slibech, některé jsou založeny na async/await, některé jsou založeny na zpětných voláních. Také píší v různých paradigmatech!
- To ztěžuje údržbu projektu. Je těžké najít chybu, pokud nemůžete přečíst kód.
Co je Web Assembly?
Odvážní kluci z Mozilla Foundation a řady dalších společností přišli s takovou věcí, jako je Web Assembly. co to je?
- Jedná se o virtuální stroj zabudovaný do prohlížeče, který podporuje binární formát.
- Binární programy se tam dostanou a jsou spouštěny téměř nativně, to znamená, že prohlížeč nemusí pokaždé analyzovat všechny „nudle“ kódu javascriptu.
- Všechny prohlížeče deklarovaly podporu.
- Protože se jedná o bytecode, můžete napsat kompilátor pro jakýkoli jazyk.
- Čtyři hlavní prohlížeče se již dodávají s podporou Web Assembly.
- Brzy očekáváme nativní podporu v Go. Tato nová architektura již byla přidána: GOARCH=wasm GOOS=js (brzy). Zatím, pokud jsem to pochopil, není funkční, ale je tam prohlášení, že v Go určitě bude.
Co teď? GopherJS
I když nemáme podporu pro Web Assembly, existuje transpiler jako GopherJS.
- Go kód je transpilován do „čistého“ Javascriptu.
- Běží ve všech prohlížečích – nejsou žádné nové funkce, které podporují pouze moderní prohlížeče (jedná se o Vanilla JS, která běží na čemkoli).
- Existuje podpora téměř všeho, co Go má, včetně goroutin a kanálů... všeho, co milujeme a co tolik známe.
- Podporována je téměř celá standardní knihovna, kromě těch balíčků, které nemá smysl podporovat v prohlížeči: syscall, net interakce (existuje síťový/http klient, ale žádný server a klient je emulován pomocí XMLHttpRequest). Obecně je k dispozici celá standardní knihovna - zde je v prohlížeči, zde je stdlib Go, který milujeme.
- Celý ekosystém balíčků v Go, všechna řešení třetích stran (šablony atd.) lze zkompilovat pomocí GopherJS a spustit v prohlížeči.
GopherJS je velmi snadné získat - je to jen běžný balíček Go. Jdeme získat a máme příkaz GopherJS pro sestavení aplikace:
Tohle je takový malý ahoj svět...
...Běžný program Go, běžná standardní knihovna fmt balíček a Binding Js pro dosažení API prohlížeče. Println bude nakonec převeden na konzolový protokol a prohlížeč napíše „Hello gophers“! Je to tak jednoduché: sestavujeme GopherJS – spustíme jej v prohlížeči – vše funguje!
co máš v tuto chvíli? Vazby
Existují vazby pro všechny populární rámce js:
- JQuery;
- Angular.js;
- D3.js pro vykreslování a práci s velkými daty;
- React.js;
- VueJS;
- dokonce existuje podpora pro Electron (to znamená, že na Electronu již můžeme psát desktopové aplikace);
- a nejzábavnější je WebGL (umíme dělat full-grafické aplikace včetně her s 3D grafikou, hudbou a všemi vychytávkami);
- a mnoho dalších vazeb na všechny populární javascriptové rámce a knihovny.
Rámec
- Existuje již vytvořený webový framework speciálně pro GopherJS - Vecty. Toto je plnohodnotná obdoba React.js, ale vyvinutá pouze v Go, se specifiky GopherJS.
- Existují herní tašky (překvapení!). Našel jsem dva nejoblíbenější:
- Engo;
- Ebiten.
Ukážu vám pár příkladů, jak to vypadá a co už můžete psát v Go:
Nebo tato možnost (nenašel jsem 3D střílečku, ale možná existuje):
co nabízím?
Nyní je front-endový průmysl v takovém stavu, že se tam nahrnou všechny jazyky, které dříve křičely z Javascriptu. Nyní bude vše zkompilováno do „Web Assemblies“. Co potřebujeme, abychom tam jako Gopherové zaujali své právoplatné místo?
Go tradičně předpokládal, že se jedná o systémový programovací jazyk a prakticky neexistují žádné knihovny pro práci s UI. Něco tam je, ale je to napůl opuštěné, napůl nefunkční.
A nyní je dobrá šance vytvořit v Go knihovny uživatelského rozhraní, které poběží na GopherJS! Konečně si můžete napsat svůj vlastní rámec! Toto je doba, kdy můžete napsat framework, a bude jedním z prvních a bude brzy přijat a budete hvězdou (pokud je to dobrý framework).
Spoustu různých balíčků, které již jsou v ekosystému Go, můžete přizpůsobit specifikům prohlížeče (například Template engine). Už budou fungovat, můžete si udělat pohodlné vazby, abyste obsah snadno vykreslili přímo v prohlížeči. Navíc můžete vytvořit například službu, která dokáže vykreslit totéž na serveru i na front-endu pomocí stejného kódu – vše, co mají front-endoví vývojáři rádi (pouze nyní v Go).
Můžete napsat hru! Jen tak pro zábavu...
To je vše, co jsem chtěl říct.
otázky
Otázka (dále jen Q): – Píšu v Go nebo Js?
AG: – Píšete rutiny, kanály, struktury, vkládání – vše v Go... Přihlásíte se k odběru události, předáte tam funkci.
In: – Takže píšu „nahým“ Js?
AG: – Ne, píšete jakoby v Go a připojujete se k API prohlížeče (API se nezměnilo). Můžete si napsat své vlastní vazby, aby se zprávy posílaly do kanálu - není to obtížné.
In: – A co mobil?
AG: – Určitě jsem viděl: existují vazby pro patch Cordova, který Js provozuje. V React Native - nevím; možná existuje, možná ne (nezajímalo mě to). Herní engine N-go podporuje obě mobilní aplikace – jak iOS, tak Android.
In: – Otázka ohledně Web Assembly. Přes kompresi a „zipování“ zabírá stále více místa... Nezabijeme frontendový svět tímto způsobem ještě více?
AG: – Web Assembly je binární formát a binární ve výchozím nastavení nemůže být v konečné verzi více než text... Jste nataženi do běhového prostředí, ale to je stejné jako přetažení standardní knihovny Javascript, když tam není, takže použijte nějaký Lodash. Nevím, kolik Lodash bere.
In: – Očividně méně než za běhu...
AG: – V „čistém“ Javascriptu?
In: - Ano. Před odesláním jej zkomprimujeme...
AG: – Ale to je text... Obecně se megabajt zdá být hodně, ale to je vše (máte celý runtime). Dále napíšete svou vlastní obchodní logiku, která zvýší vaši binární hodnotu o 1 %. Zatím nevidím, že by to zabilo frontend. Kromě toho bude Web Assembly pracovat rychleji než Javascript ze zřejmého důvodu – není nutné jej analyzovat.
In: – Toto je stále kontroverzní bod... Zatím neexistuje žádná referenční implementace „Vasma“ (Web Assembly), aby bylo možné jednoznačně posoudit. Koncepčně ano: všichni chápeme, že binární by mělo být rychlejší, ale současná implementace stejného V8 je velmi efektivní.
AG: - Ano.
In: – Kompilace tam funguje opravdu skvěle a není pravda, že to bude velká výhoda.
AG: – Web Assembly dělají i velcí chlapi.
In: – Zdá se mi, že je stále těžké posoudit Web Assembly. Konverzace se vedou již mnoho let, ale skutečných úspěchů je cítit jen málo.
AG: - Možná. Uvidíme.
In: – Nemáme problémy na backendu... Možná bychom měli tyto problémy nechat na frontendu? proč tam jít?
AG: – Musíme si udržet štáb předních pracovníků.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com