Kyiv Go Meetup Maggio 2018:
Moderatore: – Ciao a tutti! Grazie per essere qui! Oggi abbiamo due relatori ufficiali – Aleksei e Vania. Ce ne saranno altri due, se avremo tempo. Il primo relatore è Aleksei Grachov, che ci parlerà di GopherJS.
Aleksei Grachov (d'ora in poi – AG): – Sono uno sviluppatore Go e scrivo servizi web in Go. A volte mi capita di dover affrontare il frontend, ogni tanto è necessario mettere le mani direttamente lì. Voglio condividere la mia esperienza e le mie ricerche su Go nel frontend.
La leggenda è questa: prima parleremo di perché vogliamo eseguire Go nel frontend, poi discuteremo di come farlo. Ci sono due modi: Web Assembly e GopherJS. Vediamo a che punto sono queste soluzioni e cosa possiamo fare.
Qual è il problema con il frontend?
Tutti d'accordo sul fatto che con il frontend va tutto bene?
Pochi test? Compilazione lenta? Ecosistema? Bene.
Per quanto riguarda il frontend, mi piace una citazione di uno degli sviluppatori frontend che ha detto nel suo libro:
In Javascript non esiste un sistema di tipi. Ora elencherò i problemi che ho affrontato nel mio lavoro e spiegherò come vengono risolti.
Difficilmente si può parlare di sistema di tipi in Javascript – ci sono delle stringhe che rappresentano il tipo di oggetto, ma in realtà non hanno nulla a che fare con i tipi. Questo problema è stato risolto in TypeScript (un superset di Javascript) e Flow (un controllore statico dei tipi in Javascript). In effetti, il frontend è già giunto alla risoluzione del problema di un cattivo sistema di tipi in Javascript.
Non esiste una libreria standard nel browser – ci sono alcuni oggetti integrati e funzioni "magiche" nei browser. Ma la libreria standard in Javascript, di fatto, è assente. Questo problema era già stato risolto da jQuery (tutti usavano jQuery con tutti i prototipi, helper, funzioni necessarie per il lavoro). Ora invece tutti utilizzano Lodash:
Callback hell. Penso che tutti abbiano visto codice Javascript circa 5 anni fa, ed era simile a una "dripping noodle" creata da un incredibile intrico di callback. Oggi questo problema è stato risolto (con l'uscita di ES-15 o ES-16), sono stati aggiunti in Javascript i promesse e, per un po', è stato più facile respirare.
Fino a quando non è arrivato il Promice hell… Non so come l'industria frontend riesca, ma si infila sempre in qualche intrico strano. Sono riusciti a creare un hell anche con i "promessi". Hanno poi risolto questo problema introducendo un nuovo primitivo – async/await:
Il problema con l'asincronicità è stato risolto. Async/await è un primitivo piuttosto popolare in diversi linguaggi. In Python e in altri c'è questo approccio: è abbastanza buono. Il problema è risolto.
Quale problema non è stato risolto? L'aumento esponenziale della complessità dei framework, la complessità dell'ecosistema e dei programmi stessi.
- La sintassi di JavaScript è un po' strana. Tutti conosciamo i problemi con l'aggiunta di array e oggetti e altre stranezze.
- JavaScript è multi-paradigma. Ora è un sistema particolarmente attuale, dato che l'ecosistema è molto grande:
- tutti scrivono in stili diversi: chi scrive in modo strutturato, chi in modo funzionale; diversi sviluppatori scrivono in modi diversi;
- dai diversi pacchetti (packages) derivano diversi paradigmi, quando utilizzi pacchetti diversi;
- c'è davvero molto 'divertimento' con la programmazione funzionale in JavaScript - è nata la libreria Ramda e ora nessuno può leggere i programmi scritti con questa libreria.
- Tutto ciò porta un grande impatto nell'ecosistema, e si è espanso in modo incredibile. I pacchetti non sono compatibili tra loro: alcuni usano le promesse, altri async/await, altri ancora callback. E scrivono anche in diverse paradigmi!
- Questo porta a rendere difficile il supporto del progetto. È difficile trovare bug se non riesci a leggere il codice.
Che cos'è il Web Assembly?
I bravi ragazzi della Mozilla Foundation e di altre aziende hanno creato qualcosa chiamato Web Assembly. Che cos'è?
- È una macchina virtuale incorporata nel browser che supporta un formato binario.
- I programmi binari vengono trasferiti lì e vengono eseguiti quasi nativamente, quindi il browser non deve ogni volta analizzare tutta la 'pasta' di codice JavaScript.
- Tutti i browser hanno dichiarato di supportarlo.
- Poiché si tratta di bytecode, è possibile scrivere un compilatore per qualsiasi linguaggio.
- I quattro principali browser già arrivano con il supporto per Web Assembly.
- Presto ci aspettiamo il supporto nativo anche in Go. Questa nuova architettura è già stata aggiunta: GOARCH=wasm GOOS=js (presto). Fino a ora, come ho capito, non è funzionale, tuttavia c'è una dichiarazione che sicuramente sarà presente in Go.
Cosa fare ora? GopherJS
Finché non abbiamo il supporto per Web Assembly, c'è un transpiler chiamato GopherJS.
- Il codice Go viene transpiled in JavaScript 'pulito'.
- Funziona in tutti i browser: non ci sono nuove funzionalità supportate solo dai browser moderni (questo è Vanilla JS, che funziona su qualsiasi cosa).
- C'è supporto per quasi tutto ciò che esiste in Go, comprese le goroutine e i canali... – tutto ciò che amiamo e conosciamo.
- Quasi tutta la libreria standard è supportata, ad eccezione dei pacchetti che non ha senso supportare nel browser: syscall, interazioni net (c'è un client net/http, ma non un server, e il client è emulato tramite XMLHttpRequest). In generale, l'intera libreria standard è disponibile – eccola nel browser, ecco la stdlib Go, che amiamo.
- L'intero ecosistema del pacchetto in Go, tutte le soluzioni di terze parti (template e simili) possono essere compilate utilizzando GopherJS e avviate nel browser.
Ottiene GopherJS è molto facile – è un normale pacchetto Go. Facciamo go get, e abbiamo il comando GopherJS per costruire l'applicazione:
Ecco un semplice hello world...
...Un normale programma Go, un normale pacchetto fmt della libreria standard e Binding Js per accedere all'API del browser. Println sarà alla fine convertito in console log e il browser stamperà “Hello gophers”! È così semplice: facciamo GopherJS build – lo avviamo nel browser – tutto funziona!
Cosa c'è al momento? Bindings
Ci sono binding per tutti i framework js più popolari:
- JQuery;
- Angular.js;
- D3.js per la creazione di grafici e per lavorare con i big data;
- React.js;
- VueJS;
- c'è persino supporto per Electron (cioè possiamo già scrivere applicazioni desktop su «Electron»);
- e la cosa più divertente è WebGL (possiamo creare applicazioni poligonali, comprese le giochi con grafica 3D, musica e tutte le comodità);
- e molti altri binding per tutti i framework e librerie javascript più popolari.
Framework
- Esiste già un framework web progettato appositamente per GopherJS – Vecty. È un'alternativa completa a React.js, ma sviluppata in Go, con le specifiche di GopherJS.
- Ci sono anche librerie per giochi (incredibile!). Ho trovato due delle più popolari:
- Engo;
- Ebiten.
Mostrerò un paio di esempi, come appare e cosa si può già scrivere in Go:
Oppure un'altra opzione (non ho trovato uno sparatutto 3D, ma potrebbe esserci):
Cosa propongo?
Attualmente l'industria del front-end è in uno stato in cui tutti i linguaggi che prima si lamentavano di Javascript vi si riverseranno. Ora tutti si compileranno in 'Web Assembly'. Cosa ci serve per guadagnare lì un posto d'onore come 'gophers'?
In Go è tradizionalmente riconosciuto come un linguaggio di programmazione di sistema, e praticamente non esistono librerie per lavorare con l'interfaccia utente. Qualcosa c'è, ma è per metà abbandonata e per metà non funzionante.
Ecco un'ottima opportunità per sviluppare librerie UI in Go, che possano essere eseguite su GopherJS! Finalmente è possibile scrivere il proprio framework! È arrivato il momento in cui si può creare un framework ed esso sarà uno dei primi ad essere adottato precocemente, e diventerai una star (se sarà un buon framework).
È possibile adattare un'enorme quantità di pacchetti già esistenti nell'ecosistema di Go alle specificità del browser (ad esempio, un motore di template). Già funzionano, si possono creare facciate comode per rendere facile il rendering dei contenuti direttamente nel browser. Inoltre, si potrebbe realizzare un servizio in grado di renderizzare la stessa cosa sia sul server che sul front-end, usando lo stesso codice – tutto ciò che i developer front-end amano (solo che ora è su Go).
Si può scrivere un gioco! Just for fun…
Questo è tutto da parte mia.
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, passando la funzione lì.
D: – Quindi scrivo in 'nudo' Js?
AG: – No, scrivi in una sorta di Go e ti connetti all'API del browser (l'API non è cambiata). Puoi scrivere le tue facciate affinché nel canale arrivino i messaggi – non è difficile.
D: – E per quanto riguarda il mobile?
AG: – Ho visto che ci sono binding per il plugin Cordova, che l'Js lancia. In React Native – non lo so; forse ci sono, forse no (non mi sono informato molto). Il motore di gioco N-go supporta anche le applicazioni mobili – sia iOS che Android.
D: – Domanda su Web Assembly. Sta prendendo sempre più spazio, nonostante la compressione, la 'zip-azione'... Non rischiamo di uccidere ulteriormente il mondo del front-end in questo modo?
AG: – Web Assembly è un formato binario, e di default un binario non può occupare più spazio nel rilascio finale rispetto al testo... Ti attira il runtime, ma è lo stesso che cercare di includere la libreria standard di Javascript quando non ci sono, quindi usiamo qualche tipo di Lodash. Non so quanto occupi Lodash.
D: – Sicuramente meno del runtime…
AG: – In 'puro' Javascript?
D: – Sì. Infatti lo comprimiamo prima di inviarlo...
AG: – Ma questo è un testo… In generale, un megabyte sembra tanto, ma è tutto (hai il tuo runtime). Poi scrivi la tua logica di business, che aumenterà del 1% il tuo binary. Finora non vedo come questo possa compromettere il frontend. Inoltre, Web Assembly funzionerà più velocemente di Javascript per un motivo evidente: non deve essere parsato.
D: – È ancora un punto controverso… Non c'è ancora una qualche implementazione standard di "Wasm" (Web Assembly), quindi non si può giudicare senza ambiguità. Concettualmente, sì: tutti capiamo che il binary dovrebbe essere più veloce, ma l'attuale implementazione dello stesso V8 è molto efficiente.
AG: – Sì.
D: – La compilazione lì funziona davvero molto bene e non è detto che ci saranno grossi vantaggi.
AG: – Anche Web Assembly è sviluppato da grandi aziende.
D: – Finora, mi sembra ancora difficile giudicare Web Assembly. Da quanti anni si discute di questo, e i risultati concreti che possiamo toccare sono pochi.
AG: – Forse. Vedremo.
D: – Non abbiamo problemi sul backend… Potremmo lasciarli nel frontend? Perché interferire?
AG: – Dobbiamo mantenere un team di frontend.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono 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! Leggi di
Fonte: habr.com
