Incontro Kyiv Go maggio 2018:
Moderatore: - Ciao a tutti! Grazie per essere qui! Oggi abbiamo due relatori ufficiali: Lyosha e Vanya. Ce ne saranno altri due se avremo abbastanza tempo. Il primo relatore è Alexey Grachev, ci parlerà di GopherJS.
Alexey Grachev (di seguito – AG): – Sono uno sviluppatore Go e scrivo servizi web in Go. A volte devi occuparti del frontend, a volte devi accedervi manualmente. Voglio parlare della mia esperienza e ricerca su Go sul frontend.
La leggenda è questa: prima parleremo del motivo per cui vogliamo eseguire Go sul frontend, poi parleremo di come ciò può essere fatto. Esistono due modi: Web Assembly e GopherJS. Vediamo qual è lo stato di queste soluzioni e cosa si può fare.
Cosa c'è che non va nel frontend?
Sono tutti d'accordo sul fatto che va tutto bene con il frontend?
Non ci sono abbastanza test? Costruzione lenta? Ecosistema? Bene.
Per quanto riguarda il frontend, mi piace la citazione che uno degli sviluppatori del frontend ha detto nel suo libro:
Javascript non ha un sistema di tipi. Ora nominerò i problemi che ho riscontrato nel corso del mio lavoro e spiegherò come vengono risolti.
Il sistema dei tipi in generale difficilmente può essere definito un sistema dei tipi in Javasript: ci sono linee che indicano il tipo dell'oggetto, ma in realtà questo non ha nulla a che fare con i tipi. Questo problema è risolto in TypeScript (un componente aggiuntivo di Javasript) e Flow (un controllo di tipo statico in Javascript). In realtà il frontend è già arrivato al punto di risolvere il problema di un cattivo sistema di tipi in Javascript.
Non esiste una libreria standard nel browser in quanto tale: ci sono alcuni oggetti integrati e funzioni "magiche" nei browser. Ma in Javascript non esiste una libreria standard in quanto tale. Questo problema era già stato risolto una volta da jQuery (tutti usavano jQuery con tutti i prototipi, gli aiutanti, le funzioni necessarie per funzionare). Ora tutti usano Lodash:
L'inferno delle richiamate. Penso che tutti abbiano visto il codice Javascript circa 5 anni fa e sembrava un "noodle" con un'incredibile complessità di callback. Ora questo problema è stato risolto (con il rilascio di ES-15 o ES-16), sono state aggiunte delle promesse a Javascript e tutti possono respirare più tranquilli per un po'.
Finché non è arrivato l'inferno di Promice... Non so come se la cavi l'industria front-end, ma si spingono sempre in qualche strana giungla. Siamo anche riusciti a mantenere le promesse. Quindi abbiamo risolto questo problema aggiungendo una nuova primitiva - async/await:
Il problema con l'asincronia è risolto. Async/await è una primitiva abbastanza popolare in vari linguaggi. Python e altri hanno questo approccio: è abbastanza buono. Problema risolto.
Quale problema non è stato risolto? La complessità esponenzialmente crescente dei quadri, la complessità dell’ecosistema e dei programmi stessi.
- La sintassi Javascript è un po' strana. Conosciamo tutti i problemi legati all'aggiunta di un array e di un oggetto e altri scherzi.
- Javascript è multiparadigma. Questo è un sistema particolarmente urgente ora che l’ecosistema è molto grande:
- ognuno scrive in stili diversi: alcuni scrivono strutturalmente, altri scrivono funzionalmente, sviluppatori diversi scrivono in modi diversi;
- da pacchetti diversi, paradigmi diversi quando si utilizzano pacchetti diversi;
- c'è molto "divertimento" con la programmazione funzionale in Javasript: è apparsa la libreria rambda e ora nessuno può leggere i programmi scritti in questa libreria.
- Tutto ciò ha un grande impatto sull’ecosistema, che è cresciuto incredibilmente. I pacchetti sono incompatibili tra loro: alcuni si basano su promesse, altri su async/await, altri su callback. Scrivono anche in paradigmi diversi!
- Ciò rende il progetto difficile da mantenere. È difficile trovare un bug se non riesci a leggere il codice.
Cos'è l'assemblaggio Web?
I coraggiosi ragazzi della Mozilla Foundation e di numerose altre società hanno inventato qualcosa come Web Assembly. Cos'è questo?
- Questa è una macchina virtuale integrata nel browser che supporta il formato binario.
- I programmi binari arrivano lì e vengono eseguiti quasi in modo nativo, ovvero il browser non ha bisogno di analizzare ogni volta tutti i "noodles" del codice javascript.
- Tutti i browser hanno dichiarato il supporto.
- Poiché si tratta di bytecode, puoi scrivere un compilatore per qualsiasi lingua.
- Quattro browser principali sono già forniti con il supporto Web Assembly.
- Ci aspettiamo presto il supporto nativo in Go. Questa nuova architettura è già stata aggiunta: GOARCH=wasm GOOS=js (presto). Finora, a quanto ho capito, non è funzionale, ma si afferma che sarà sicuramente in Go.
Cosa fare adesso? GopherJS
Sebbene non disponiamo del supporto per Web Assembly, esiste un transpiler come GopherJS.
- Il codice Go viene tradotto in Javascript “puro”.
- Funziona in tutti i browser: non ci sono nuove funzionalità supportate solo dai browser moderni (questo è Vanilla JS, che funziona su qualsiasi cosa).
- C'è il supporto per quasi tutto ciò che Go ha, comprese goroutine e canali... tutto ciò che amiamo e conosciamo così tanto.
- È supportata quasi l'intera libreria standard, ad eccezione di quei pacchetti che non ha senso supportare nel browser: syscall, interazioni net (c'è un client net/http, ma nessun server, e il client viene emulato tramite XMLHttpRequest). In generale, è disponibile l'intera libreria standard: eccola nel browser, ecco stdlib di Go, che adoriamo.
- L'intero ecosistema di pacchetti in Go, tutte le soluzioni di terze parti (template, ecc.) possono essere compilati utilizzando GopherJS ed eseguiti nel browser.
GopherJS è molto facile da ottenere: è semplicemente un normale pacchetto Go. Andiamo a prendere e abbiamo un comando GopherJS per creare l'applicazione:
Ciao mondo, questo è così piccolo...
...Un normale programma Go, un normale pacchetto fmt della libreria standard e Binding Js per raggiungere l'API del browser. Println alla fine verrà convertito nel log della console e il browser scriverà "Hello gophers"! È semplicissimo: costruiamo GopherJS – lo lanciamo nel browser – tutto funziona!
Cos'hai in questo momento? Legami
Esistono collegamenti per tutti i framework js più diffusi:
- JQuery;
- Angular.js;
- D3.js per tracciare e lavorare con i big data;
- React.js;
- VueJS;
- c'è anche il supporto per Electron (ovvero possiamo già scrivere applicazioni desktop su Electron);
- e la cosa più divertente è WebGL (possiamo realizzare applicazioni completamente grafiche, inclusi giochi con grafica 3D, musica e tutte le chicche);
- e molti altri collegamenti a tutti i framework e librerie Javascript più diffusi.
Contesto
- Esiste già un framework web sviluppato appositamente per GopherJS - Vecty. Questo è un analogo a tutti gli effetti di React.js, ma sviluppato solo in Go, con le specificità di GopherJS.
- Ci sono i carnieri (sorpresa!). Ho trovato i due più popolari:
- Engo;
- Ebiten.
Ti mostrerò un paio di esempi di come appare e cosa puoi già scrivere in Go:
Oppure questa opzione (non sono riuscito a trovare uno sparatutto 3D, ma forse esiste):
Cosa sto offrendo?
Ora l'industria front-end è in uno stato tale che tutte le lingue che prima piangevano da Javascript si precipiteranno lì. Ora tutto verrà compilato in “Web Assemblies”. Di cosa abbiamo bisogno per prendere il posto che ci spetta come Gopher?
Go tradizionalmente presuppone che si tratti di un linguaggio di programmazione di sistema e praticamente non ci sono librerie per lavorare con l'interfaccia utente. Qualcosa c'è, ma è per metà abbandonato e per metà non funzionante.
E ora c'è una buona occasione per creare librerie dell'interfaccia utente in Go che possano essere eseguite su GopherJS! Puoi finalmente scrivere il tuo framework! Questo è il momento in cui puoi scrivere un framework, e sarà uno dei primi e verrà adottato in anticipo, e sarai una star (se è un buon framework).
Puoi adattare molti pacchetti diversi già presenti nell'ecosistema Go alle specifiche del browser (ad esempio, Template engine). Funzioneranno già, puoi creare comode associazioni in modo da poter facilmente visualizzare il contenuto direttamente nel browser. Inoltre, puoi creare, ad esempio, un servizio in grado di eseguire il rendering della stessa cosa sul server e sul front-end, utilizzando lo stesso codice: tutto ciò che piace agli sviluppatori front-end (solo ora in Go).
Puoi scrivere un gioco! Solo per divertimento...
Ho tutto
domande
Domanda (di seguito denominata Q): – Scrivo in Go o Js?
AG: – Scrivi routine, canali, strutture, incorporamenti – tutto in Go... Ti iscrivi a un evento, passi una funzione lì.
A: – Quindi scrivo in J “nuda”?
AG: – No, scrivi come in Go e ti connetti all'API del browser (l'API non è cambiata). Puoi scrivere i tuoi collegamenti in modo che i messaggi vengano inviati al canale: non è difficile.
A: – E il cellulare?
AG: – Ho sicuramente visto: ci sono attacchi per la patch Cordova che Js esegue. In React Native: non lo so; forse c’è, forse no (non mi interessava particolarmente). Il motore di gioco N-go supporta entrambe le applicazioni mobili, sia iOS che Android.
A: – Domanda sull'assemblaggio Web. Viene occupato sempre più spazio, nonostante la compressione e lo “zipping”... Non uccideremo così ancora di più il mondo front-end?
AG: – Web Assembly è un formato binario e il binario per impostazione predefinita non può essere nella versione finale più del testo... Sei attratto dal runtime, ma questo equivale a trascinare fuori la libreria Javascript standard quando non è presente, quindi noi usa un po' di Lodash. Non so quanto Lodash prende.
A: – Ovviamente meno del tempo di esecuzione...
AG: – In Javascript “puro”?
A: - SÌ. Lo comprimiamo prima di inviarlo...
AG: – Ma questo è testo... In generale, un megabyte sembra molto, ma è tutto (hai l'intero runtime). Successivamente, scrivi la tua logica aziendale, che aumenterà il tuo binario dell'1%. Finora non vedo che questo uccida il frontend. Inoltre, Web Assembly funzionerà più velocemente di Javascript per l'ovvia ragione: non è necessario analizzarlo.
A: – Questo è ancora un punto controverso... Non esiste ancora alcuna implementazione di riferimento di “Vasma” (Web Assembly) in modo che si possa giudicare in modo inequivocabile. Concettualmente sì: capiamo tutti che il binario dovrebbe essere più veloce, ma l'attuale implementazione dello stesso V8 è molto efficiente.
AG: - Sì.
A: – La compilazione lì funziona davvero molto bene e non è un dato di fatto che ci sarà un grande vantaggio.
AG: – Anche il Web Assembly è realizzato da ragazzi grandi.
A: – Mi sembra che sia ancora difficile giudicare Web Assembly. Sono ormai molti anni che se ne parla, ma sono pochi i risultati concreti che si possono percepire.
AG: - Forse. Vedremo.
A: – Non abbiamo problemi sul backend… Forse dovremmo lasciare questi problemi sul frontend? Perché andarci?
AG: – Dobbiamo mantenere uno staff di lavoratori in prima linea.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com