Kyiv Go Meetup Maggio 2018:
Moderatore: – Ciao a tutti! Grazie per essere qui! Oggi abbiamo due relatori ufficiali – Lesha e Vanya. Ce ne saranno altri due, se abbiamo tempo. Il primo relatore è Alexey Grachev, che ci parlerà di GopherJS.
Alexey Grachev (di seguito – AG): – Sono uno sviluppatore Go e scrivo servizi web in Go. A volte mi capita di dover affrontare il frontend, e talvolta devo metterci le mani. Voglio condividere la mia esperienza e le mie ricerche su Go nel frontend.
La leggenda è la seguente: prima parleremo del motivo per cui vogliamo eseguire Go nel frontend, poi discuteremo di come farlo. Ci sono due strade – Web Assembly e GopherJS. Vediamo in che stato sono queste soluzioni e cosa possiamo fare.
Cosa c'è che non va con il frontend?
Siete tutti d'accordo che il frontend va bene?
Ci sono pochi test? Compilazione lenta? Ecosistema? Va bene.
Per quanto riguarda il frontend, mi piace la citazione di uno degli sviluppatori frontend nel suo libro:
In Javascript non c'è un sistema di tipi. Ora inizierò a elencare i problemi che ho incontrato nel mio lavoro e a spiegare come vengono risolti.
Definire un sistema di tipi in JavaScript è piuttosto complicato: ci sono stringhe che rappresentano il tipo di oggetto, ma in realtà non hanno molto a che fare con i tipi. Questo problema è stato risolto in TypeScript (un'estensione di JavaScript) e Flow (un verificatore statico dei tipi in JavaScript). In effetti, il frontend ha trovato una soluzione al problema della scarsa gestione dei tipi in JavaScript.
Non esiste una vera e propria libreria standard nel browser: ci sono alcuni oggetti incorporati e funzioni "magiche" nei browser. Ma in JavaScript, la libreria standard non è presente. Questo problema era già stato affrontato da jQuery (tutti usavano jQuery con tutti i suoi prototipi, helper e funzioni necessarie per il funzionamento). Oggi tutti usano Lodash:
Callback hell. Penso che tutti abbiano visto codice JavaScript circa 5 anni fa, ed era simile a un "nido" di callback estremamente complessi. Oggi questo problema è stato risolto (con il rilascio di ES-15 o ES-16), sono stati introdotti in JavaScript i promise, e per un po' tutti hanno respirato più facilmente.
Fino a quando non è arrivato Promice hell... Non so come faccia l'industria del frontend, ma si complicano la vita in modi strani. Sono riusciti a creare un «hell» anche con i «promises». Poi hanno deciso di risolvere il problema introducendo un nuovo primitivo: async/await.
Con l'asincronia, il problema è risolto. Async/await è un primitivo abbastanza popolare in vari linguaggi. In Python e in altri c'è questo approccio, ed è piuttosto buono. Problema risolto.
Quale problema non è risolto? La complessità dei framework in crescita geometrica, la complessità dell'ecosistema e dei programmi stessi.
- La sintassi di Javascript è un po' strana. Tutti noi conosciamo i problemi legati alla somma di array e oggetti e altre peculiarità.
- Javascript è multi-paradigma. Ora è un sistema particolarmente necessario, dato che l'ecosistema è molto ampio:
- tutti scrivono in stili diversi – c'è chi scrive in modo strutturato, chi in modo funzionale, diversi sviluppatori seguono approcci diversi;
- da diversi pacchetti (packages) provengono paradigmi diversi quando si utilizzano pacchetti differenti.
- c'è molto "divertimento" con la programmazione funzionale in JavaScript – è nata la libreria rambda e ora nessuno può leggere i programmi scritti in essa.
- Tutto ciò porta a un grande impatto nell'ecosistema, che è cresciuto in modo incredibile. I pacchetti non sono compatibili: alcuni usano le promise, altri async/await, altri ancora i callback. Inoltre, sono scritti in paradigmi diversi!
- Questo rende difficile mantenere il progetto. È complicato trovare un bug se non riesci a leggere il codice.
Che cos'è il Web Assembly?
I ragazzi della Mozilla Foundation e di altre aziende hanno ideato qualcosa di chiamato Web Assembly. Che cos'è?
- È una macchina virtuale integrata nel browser che supporta un formato binario.
- I programmi binari vengono eseguiti praticamente in modo nativo, quindi il browser non deve analizzare ogni volta tutta la "grammatica" del codice JavaScript.
- Tutti i browser hanno dichiarato il loro supporto.
- Poiché è bytecode, è possibile scrivere un compilatore per qualsiasi linguaggio.
- I quattro principali browser sono già dotati di supporto per il Web Assembly.
- Presto stiamo aspettando il supporto nativo in Go. Questa nuova architettura è già stata aggiunta: GOARCH=wasm GOOS=js (presto). Per ora, a quanto ne so, non è funzionante, ma c'è una dichiarazione che conferma che questo arriverà sicuramente in Go.
Cosa fare adesso? GopherJS
Finché non abbiamo il supporto per Web Assembly, esiste un transpiler chiamato GopherJS.
- Il codice scritto in Go viene transpile in JavaScript "pulito".
- Funziona in tutti i browser – non ci sono nuove funzionalità supportate solo dai browser moderni (è Vanilla JS, che funziona su qualsiasi piattaforma).
- C'è supporto per quasi tutto ciò che è presente in Go, incluse le goroutine e i canali... – tutto ciò che conosciamo e amiamo.
- Quasi tutta la libreria standard è supportata, tranne per i pacchetti che non ha senso supportare nel browser: syscall, interazioni di rete (c'è un client net/http, ma non un server, e il client viene emulato tramite XMLHttpRequest). Nel complesso, l'intera libreria standard è disponibile – eccola nel browser, questa è la stdlib Go che amiamo.
- L'intero ecosistema dei pacchetti in Go, tutte le soluzioni di terze parti (template e altro), possono essere compilati con GopherJS e eseguiti nel browser.
Ottenere GopherJS è molto semplice: si tratta di un pacchetto Go standard. Facciamo go get e avremo il comando GopherJS per costruire l'applicazione:
Ecco un piccolo hello world...
...Un normale programma Go, il pacchetto fmt della libreria standard e Binding Js per accedere all'API del browser. Println alla fine verrà convertito in console log e il browser scriverà “Hello gophers”! È così semplice: facciamo GopherJS build – lo avviamo nel browser – e tutto funziona!
Cosa c'è attualmente?
Ci sono binding per tutti i principali framework js:
- JQuery;
- Angular.js;
- D3.js per la creazione di grafici e lavoro con grandi dati;
- React.js;
- VueJS;
- c'è anche supporto per Electron (quindi già ora possiamo scrivere applicazioni desktop su ‘Electron’);
- e la cosa più divertente è WebGL (possiamo creare applicazioni poligonali, inclusi giochi con grafica 3D, musica e tutti i fronzoli);
- e molti altri binding per tutti i principali framework e librerie javascript.
Framework
- Esiste già un framework web sviluppato appositamente per GopherJS – Vecty. È un'alternativa completa a React.js, ma sviluppato in Go, con le peculiarità di GopherJS.
- Ci sono anche motori di gioco (inaspettatamente!). Ne ho trovati due tra i più popolari:
- Engo;
- Ebiten.
Mostrerò un paio di esempi di come appare e cosa si può già scrivere in Go:
Oppure questa variante (non ho trovato un FPS 3D, ma forse esiste):
Cosa propongo?
Attualmente l'industria del front-end è in uno stato tale che tutti i linguaggi che prima si lamentavano di JavaScript stanno per affluire. Ora tutti saranno compilati in "Web Assembly". Cosa ci serve per avere un posto di rilievo lì come programmatori Go?
Tradizionalmente, Go è considerato un linguaggio di programmazione di sistema e praticamente non ci sono librerie per lavorare con l'interfaccia utente. Esiste qualcosa, ma è per metà abbandonato e per metà non funzionale.
Ecco, c'è una buona opportunità per creare librerie UI in Go che funzioneranno su GopherJS! Finalmente si può scrivere il proprio framework! È arrivato il momento in cui puoi creare un framework, e sarà tra i primi a essere adottato e diventerai una star (se sarà un buon framework).
È possibile adattare un sacco di diversi pacchetti già presenti nell'ecosistema Go alle specifiche del browser (ad esempio, un motore di template). Funzionano già, e si possono creare dettagli pratici per rendere facile il rendering dei contenuti direttamente nel browser. Inoltre, si può realizzare un servizio in grado di fare lo stesso sul server e sul frontend, utilizzando lo stesso codice — proprio come piace ai frontend developer (solo che ora è fatto in Go).
Si può creare un gioco! Just for fun…
Ho finito.
Domande
Domanda (di seguito – D): – Scrivo in Go o in Js?
AG: – Scrivi in Go, routine, canali, strutture, embedding – è tutto... Ti iscrivi a un evento e ci passi una funzione.
D: – Quindi scrivo in 'puro' Js?
AG: – No, scrivi come se fosse Go e ti connetti all'API del browser (l'API non è cambiata). Puoi scrivere i tuoi ganci per ricevere messaggi nel canale – non è difficile.
D: – E per il mobile?
AG: – Ho visto: ci sono binding per il pacchetto Cordova che Js avvia. In React Native – non lo so; magari ci sono, oppure no (non mi sono interessato molto). Il motore di gioco N-go supporta anche le applicazioni mobili – sia iOS che Android.
D: – Domanda su Web Assembly. Gli spazi stanno diventando sempre più affollati, nonostante la compressione e la "zippatura"... Non rischiamo di danneggiare ulteriormente il mondo del frontend in questo modo?
AG: – Web Assembly è un formato binario, e un binario per impostazione predefinita non può essere maggiore nel rilascio finale rispetto al testo... Sei attratto dal runtime, ma è lo stesso di tirare dentro una libreria standard di Javascript, quando non c'è, quindi utilizziamo qualcosa come Lodash. Non so quanto spazio occupi Lodash.
D: – Sicuramente meno del runtime...
AG: – In Javascript "puro"?
D: – Sì. Lo comprimiamo prima di inviarlo...
AG: – Ma questo è testo... In generale, un megabyte sembra tanto, ma è tutto (hai tutto il runtime). Poi scrivi la tua logica di business, che aumenterà il tuo binario dell'1%. Finora non vedo come questo possa compromettere il frontend. Inoltre, Web Assembly funzionerà più velocemente di Javascript per un motivo ovvio: non deve essere analizzato.
D: – Questo è un punto ancora controverso... Non c'è ancora una realizzazione standard di "Wasm" (Web Assembly) per poter giudicare chiaramente. Concettualmente - sì: tutti capiamo che un binario dovrebbe essere più veloce, ma l'attuale realizzazione di V8 è molto efficace.
AG: – Sì.
D: – La compilazione qui funziona davvero molto bene e non è affatto scontato che ci sarà un grande vantaggio.
AG: – Anche i grandi nomi stanno utilizzando Web Assembly.
D: – Al momento, mi sembra ancora difficile giudicare Web Assembly. Ci sono anni di discussioni, ma poche realizzazioni tangibili.
AG: – Forse. Vedremo.
D: – Non abbiamo problemi sul backend… Magari è meglio lasciare questi problemi sul frontend? Perché intromettersi?
AG: – Dobbiamo mantenere un team di frontend.
Un po' di pubblicità 🙂
Grazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, , un'alternativa unica ai server entry-level, che abbiamo creato per te: (disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Scopri di più su
Fonte: habr.com
