Kyiv Go Meetup mei 2018:
Presentator: – Hallo allemaal! Dank dat jullie hier zijn! Vandaag hebben we twee officiële sprekers – Ljoesja en Vania. Er komen er nog twee, als we tijd genoeg hebben. De eerste spreker is Alexej Gračev, hij zal ons vertellen over GopherJS.
Alexej Gračev (verder – AG): – Ik ben een Go-ontwikkelaar en schrijf webservices in Go. Soms moet ik met de frontend bezig zijn, soms moet ik daar zelf aan de slag. Ik wil mijn ervaringen en onderzoeken met Go aan de frontend delen.
Het verhaal is als volgt: eerst bespreken we waarom we Go aan de frontend willen draaien, daarna bespreken we hoe we dat kunnen doen. Er zijn twee wegen – Web Assembly en GopherJS. Laten we kijken in welke staat deze oplossingen verkeren en wat we ermee kunnen doen.
Wat is er mis met de frontend?
Is iedereen het erover eens dat alles goed gaat met de frontend?
Te weinig tests? Langzame builds? Ecosysteem? Goed.
Wat betreft de frontend houd ik van een citaat van een van de frontend-ontwikkelaars in zijn boek:
JavaScript heeft geen typesysteem. Nu ga ik de problemen opsommen waarmee ik in mijn werk te maken heb gehad en uitleggen hoe ze worden aangepakt.
Het typesysteem is eigenlijk moeilijk te beschrijven als een typesysteem in JavaScript – er zijn strings die het type van een object aangeven, maar dat heeft in feite niets met types te maken. Dit probleem is opgelost in TypeScript (een uitbreiding van JavaScript) en Flow (een static type checker voor JavaScript). Eigenlijk heeft de frontend al een oplossing gevonden voor het probleem van het slechte typesysteem in JavaScript.
Er is eigenlijk geen standaardbibliotheek in de browser – er zijn een aantal ingebouwde objecten en "magische" functies in de browsers. Maar in JavaScript is er als zodanig geen standaardbibliotheek beschikbaar. Dit probleem werd ooit opgelost door jQuery (iedereen gebruikte jQuery met alle prototypes, helpers en functies die nodig zijn voor het werk). Tegenwoordig gebruikt iedereen Lodash:
Callback hell. Ik denk dat iedereen de JavaScript-code van ongeveer 5 jaar geleden wel heeft gezien, die leek op "noodle" van een ongelooflijke verwevenheid van callbacks. Tegenwoordig is dit probleem opgelost (met de release van ES-15 of ES-16), er zijn beloftes (promises) aan JavaScript toegevoegd en dat maakte het voor iedereen iets gemakkelijker.
Tot de komst van Promise hell… Ik weet niet hoe de frontend-industrie het voor elkaar krijgt, maar ze drijven zichzelf voortdurend in vreemde situaties. Zelfs met "promises" hebben ze hell weten te creëren. Toen hebben ze dat probleem opgelost door een nieuwe primitief toe te voegen – async/await:
Met async is het probleem opgelost. Async/await is een vrij populaire primitief in verschillende talen. In Python en andere talen is er een dergelijke benadering - het is behoorlijk goed. Het probleem is opgelost.
Wat is er nog niet opgelost? De exponentieel groeiende complexiteit van frameworks, de complexiteit van ecosystemen en de software zelf.
- De syntaxis van Javascript is een beetje vreemd. We kennen allemaal de problemen met het samenvoegen van een array en een object en andere leukigheden.
- Javascript is multiparadigma. Dit is nu vooral een actuele kwestie, omdat het ecosysteem enorm groot is:
- iedereen schrijft in verschillende stijlen - sommigen schrijven structureel, anderen functioneel, verschillende ontwikkelaars schrijven op verschillende manieren;
- uit verschillende pakketten (packages) komen verschillende paradigma's voort, wanneer je verschillende pakketten gebruikt;
- er is veel "plezier" met functioneel programmeren in Javascript - de rambda-bibliotheek is verschenen en nu kan niemand de programma's lezen die in deze bibliotheek zijn geschreven.
- Dit heeft een grote impact op het ecosysteem en het is ongelooflijk gegroeid. Pakketten zijn met elkaar incompatibel: sommigen gebruiken promises, sommigen async/await, anderen callbacks. Ze schrijven ook in verschillende paradigma's!
- Dit leidt ertoe dat een project moeilijk te onderhouden is. Het is moeilijk om een bug te vinden als je de code niet kunt lezen.
Wat is Web Assembly?
De dappere jongens van de Mozilla Foundation en een aantal andere bedrijven hebben iets bedacht dat Web Assembly heet. Wat is dat?
- Het is een virtuele machine die in de browser is ingebouwd en die een binair formaat ondersteunt.
- Binaire programma's worden daar naartoe gestuurd en worden praktisch native uitgevoerd, dat wil zeggen dat de browser niet elke keer de hele 'spaghetti' van javascript-code hoeft te parseren.
- Alle browsers hebben ondersteuning aangekondigd.
- Aangezien dit bytecode is, kan je een compiler voor elke taal schrijven.
- De vier belangrijkste browsers worden al geleverd met ondersteuning voor Web Assembly.
- We verwachten binnenkort native ondersteuning in Go. Deze nieuwe architectuur is al toegevoegd: GOARCH=wasm GOOS=js (binnenkort). Voorlopig, zoals ik begrijp, is het nog niet operationeel, maar er is een verklaring dat dit zeker in Go zal komen.
Wat te doen nu? GopherJS
Totdat we ondersteuning voor Web Assembly hebben, is er een transpiler genaamd GopherJS.
- Code in Go wordt getranspiled naar 'schone' Javascript.
- Het wordt in alle browsers uitgevoerd - er zijn geen nieuwe functies die alleen door moderne browsers worden ondersteund (dit is Vanilla JS dat overal draait).
- Er is ondersteuning voor bijna alles wat er in Go is, inclusief goroutines en kanalen... - alles wat we zo liefhebben en kennen.
- Bijna de hele standaardbibliotheek is ondersteund, met uitzondering van die pakketten die geen zin hebben om in de browser te ondersteunen: syscall, netwerkinteracties (er is een net/http-client, maar geen server, en de client wordt nagebootst via XMLHttpRequest). Over het algemeen is de hele standaardbibliotheek beschikbaar - hier is hij in de browser, hier is de stdlib Go, die we zo liefhebben.
- Het hele ecosysteem van pakketten in Go, alle derde partijen (sjablonen en dergelijke) kunnen worden gecompileerd met GopherJS en in de browser worden uitgevoerd.
GopherJS is heel gemakkelijk te verkrijgen - het is een gewone Go-pakket. We doen go get, en dan hebben we de GopherJS-commando om de applicatie te bouwen:
Hier is zo'n klein hello world...
...Een gewone Go-programma, een gewoon fmt-pakket van de standaardbibliotheek en Binding Js om toegang te krijgen tot de browser-API. Println zal uiteindelijk worden omgezet in console log en de browser zal 'Hello gophers!' schrijven! Zo simpel is het: we doen GopherJS build - draaien in de browser - alles werkt!
Wat is er op dit moment beschikbaar? Bindings
Er zijn bindings voor alle populaire js-frameworks:
- JQuery;
- Angular.js;
- D3.js voor grafieken en het werken met grote data;
- React.js;
- VueJS;
- er is zelfs ondersteuning voor Electron (dat betekent dat we al desktopapplicaties kunnen schrijven op 'Electron');
- en het leukste is - dat is WebGL (we kunnen full-graphic applicaties maken, inclusief games met 3D-graphics, muziek en alle toeters en bellen);
- en nog veel meer bindings voor alle populaire javascript-frameworks en bibliotheken.
Framework
- Er is al een speciaal voor GopherJS ontwikkelde webframework - Vecty. Dit is een volwaardig alternatief voor React.js, maar dan ontwikkeld in Go, met de specificiteit van GopherJS.
- Er zijn game-engines (verrassend!). Ik heb twee van de meest populaire gevonden:
- Engo;
- Ebiten.
Ik zal een paar voorbeelden tonen van hoe dit eruit ziet en wat er nu al geschreven kan worden in Go:
Of deze optie (ik heb geen 3D-shooter gevonden, maar misschien is die er):
Wat stel ik voor?
De front-end industrie bevindt zich nu in een staat waarin alle talen die eerder huilden om Javascript, zich nu zullen storten op het compileren naar 'Web Assembly'. Wat hebben we nodig om daar een waardige plek te veroveren als 'gophers'?
In Go, it is traditionally considered a system programming language, and there are almost no libraries for working with UI. There are some, but they are half-abandoned and half non-functional.
And here it is – a good chance to create UI libraries in Go that will run on GopherJS! Finally, you can write your own framework! The time has come when you can write a framework that will be one of the first to gain early adoption, and you will be a star (if it's a good framework).
You can adapt numerous existing packages from the Go ecosystem to the browser's specifics (for example, a template engine). They are already functional, and you can create convenient wrappers to easily render content right in the browser. Plus, you could create a service that can render the same thing on the server and the frontend using the same code – just like frontend developers love (only now in Go).
You can write a game! Just for fun…
That's all from me.
Vragen
Question (hereafter - Q): – Am I writing in Go or in JS?
AG: – You are writing in Go routines, channels, structures, embedding – everything... You subscribe to an event, passing a function to it.
V: – So I am writing in ‘bare’ JS?
AG: – No, you write as if in Go and connect to the browser's API (the API itself hasn't changed). You can write your own wrappers so that messages come into the channel – it's not difficult.
V: – What about mobile?
AG: – I definitely saw: there are bindings for the Cordova patch that JS runs. As for React Native – I don’t know; there may be some, or maybe not (I haven’t looked into it much). The game engine N-go supports both mobile applications – iOS and Android.
V: – A question about Web Assembly. It is taking up more and more space, despite compression and being ‘zipped’... Are we not killing the frontend world even more this way?
AG: – Web Assembly is a binary format, and by default, binaries cannot be larger than text in the final release... You are drawn to the runtime, but it's the same as pulling in the standard JavaScript library when it’s not there, which is why we use some Lodash. I don't know how much Lodash takes up.
V: – Clearly less than the runtime...
AG: – In ‘pure’ JavaScript?
V: – Yes. We compress it before sending...
AG: – Maar dit is gewoon tekst... Over het algemeen is een megabyte veel, maar dat is alles (je hebt de volledige runtime). Vervolgens schrijf je je bedrijfslogica die je binary met 1% verhoogt. Tot nu toe zie ik niet dat dit de frontend schaadt. Bovendien zal Web Assembly sneller werken dan Javascript om een voor de hand liggende reden – het hoeft niet geparsed te worden.
V: – Het is nog een discutabel punt... Er is nog geen standaardimplementatie van 'Wasmer' (Web Assembly) die ons in staat stelt om definitieve conclusies te trekken. Conceptueel klopt het: we begrijpen allemaal dat de binary sneller moet zijn, maar de huidige implementatie van V8 is heel efficiënt.
AG: – Ja.
V: – De compilatie daar werkt echt heel goed en het is niet zeker dat er sprake zal zijn van een groot voordeel.
AG: – Web Assembly wordt ook ontwikkeld door grote bedrijven.
V: – Tot nu toe lijkt het mij nog lastig om Web Assembly te beoordelen. Al jaren praten we erover, maar er zijn weinig echte prestaties die we kunnen aanraken.
AG: – Misschien. We zullen het zien.
V: – We hebben geen problemen aan de backend... Misschien moeten we deze problemen in de frontend laten? Waarom daarheen gaan?
AG: – We moeten een team van frontend-ontwikkelaars aanhouden.
Een beetje reclame 🙂
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — vanaf $99! Lees over hoe
Bron: habr.com
