Kyiv Go Meetup mai 2018:
Moderator: - Salutare tuturor! Vă mulțumim că sunteți aici! Astăzi avem doi vorbitori oficiali - Lyosha și Vanya. Vor mai fi două dacă avem suficient timp. Primul vorbitor este Alexey Grachev, el ne va vorbi despre GopherJS.
Alexey Grachev (în continuare – AG): – Sunt dezvoltator Go și scriu servicii web în Go. Uneori trebuie să te ocupi de front-end, alteori trebuie să intri manual. Vreau să vorbesc despre experiența și cercetările mele despre Go pe front-end.
Legenda este următoarea: mai întâi vom vorbi despre motivul pentru care vrem să rulăm Go pe front-end, apoi vom vorbi despre cum se poate face acest lucru. Există două moduri - Web Assembly și GopherJS. Să vedem care este stadiul acestor soluții și ce se poate face.
Ce este în neregulă cu frontend-ul?
Toată lumea este de acord că totul este în regulă cu frontend-ul?
Nu sunt suficiente teste? Construcție lentă? Ecosistem? Amenda.
În ceea ce privește frontend-ul, îmi place citatul pe care unul dintre dezvoltatorii de frontend a spus în cartea sa:
Javascript nu are un sistem de tip. Acum voi numi problemele pe care le-am întâlnit în timpul muncii mele și voi explica cum sunt rezolvate.
Sistemul de tipuri în general poate fi numit cu greu un sistem de tipuri în Javasript - există linii care indică tipul obiectului, dar de fapt acest lucru nu are nimic de-a face cu tipurile. Această problemă este rezolvată în TypeScript (un add-on la Javasript) și Flow (un verificator de tip static în Javascript). De fapt, frontend-ul a ajuns deja la punctul de a rezolva problema unui sistem de tip prost în Javascript.
Nu există nicio bibliotecă standard în browser ca atare - există unele obiecte încorporate și funcții „magice” în browsere. Dar în Javascript nu există nicio bibliotecă standard ca atare. Această problemă a fost deja rezolvată o dată de jQuery (toată lumea a folosit jQuery cu toate prototipurile, ajutoarele, funcțiile necesare pentru a funcționa). Acum toată lumea folosește Lodash:
Reapelare iadul. Cred că toată lumea a văzut codul Javascript în urmă cu aproximativ 5 ani și arăta ca un „taței” cu o complexitate incredibilă de apeluri inverse. Acum această problemă a fost rezolvată (odată cu lansarea ES-15 sau ES-16), au fost adăugate promisiuni la Javascript și toată lumea poate respira mai ușor pentru o vreme.
Până când a sosit iadul Promice... Nu știu cum se descurcă industria front-end, dar ei se conduc mereu într-o junglă ciudată. De asemenea, am reușit să facem iadul promisiunilor. Apoi am rezolvat această problemă adăugând o nouă primitivă - async/wait:
Problema cu asincronia este rezolvată. Async/wait este o primitivă destul de populară în diferite limbi. Python și alții au această abordare - este destul de bună. Problema rezolvata.
Ce problema nu este rezolvata? Creșterea exponențială a complexității cadrelor, a complexității ecosistemului și a programelor în sine.
- Sintaxa Javascript este puțin ciudată. Știm cu toții problemele legate de adăugarea unei matrice și a unui obiect și alte glume.
- Javascript este multi-paradigma. Acesta este un sistem deosebit de presant acum, când ecosistemul este foarte mare:
- toată lumea scrie în stiluri diferite - unii scriu structural, alții scriu funcțional, diferiți dezvoltatori scriu în moduri diferite;
- din pachete diferite, paradigme diferite când utilizați pachete diferite;
- există multă „distracție” cu programarea funcțională în Javasript - a apărut biblioteca rambda și acum nimeni nu poate citi programele scrise în această bibliotecă.
- Toate acestea au un impact mare asupra ecosistemului și au crescut incredibil. Pachetele sunt incompatibile între ele: unele se bazează pe promisiuni, altele se bazează pe async/wait, altele se bazează pe apeluri inverse. Ei scriu și în diferite paradigme!
- Acest lucru face ca proiectul să fie dificil de întreținut. Este greu să găsești o eroare dacă nu poți citi codul.
Ce este Web Assembly?
Băieții curajoși de la Fundația Mozilla și o serie de alte companii au venit cu așa ceva ca Web Assembly. Ce este asta?
- Aceasta este o mașină virtuală încorporată în browser care acceptă formatul binar.
- Programele binare ajung acolo și sunt executate aproape nativ, adică browserul nu trebuie să analizeze de fiecare dată toți „fideii” codului javascript.
- Toate browserele au declarat suport.
- Deoarece acesta este bytecode, puteți scrie un compilator pentru orice limbă.
- Patru browsere majore sunt livrate deja cu suport Web Assembly.
- Ne așteptăm la asistență nativă în Go în curând. Această nouă arhitectură a fost deja adăugată: GOARCH=wasm GOOS=js (în curând). Până acum, din câte am înțeles, nu este funcțional, dar există o declarație că va fi cu siguranță în Go.
Ce e de făcut acum? GopherJS
Deși nu avem suport pentru Web Assembly, există un transpiler precum GopherJS.
- Codul Go este transpilat în Javascript „pur”.
- Rulează în toate browserele - nu există funcții noi care să fie acceptate doar de browserele moderne (acesta este Vanilla JS, care rulează pe orice).
- Există suport pentru aproape tot ceea ce are Go, inclusiv goroutine și canale... tot ceea ce iubim și știm atât de mult.
- Aproape întreaga bibliotecă standard este acceptată, cu excepția acelor pachete pe care nu are sens să le suporte în browser: syscall, interacțiuni net (există un client net/http, dar fără server, iar clientul este emulat prin XMLHttpRequest). În general, întreaga bibliotecă standard este disponibilă - aici este în browser, aici este stdlib-ul Go, care ne place.
- Întregul ecosistem de pachete din Go, toate soluțiile terțe (șabloane etc.) pot fi compilate folosind GopherJS și rulate în browser.
GopherJS este foarte ușor de obținut - este doar un pachet Go obișnuit. Mergem să obținem și avem o comandă GopherJS pentru a construi aplicația:
Aceasta este o lume atât de mică de salut...
...Un program Go obișnuit, un pachet fmt de bibliotecă standard obișnuit și Binding Js pentru a ajunge la API-ul browserului. Println va fi convertit în cele din urmă în jurnalul consolei, iar browserul va scrie „Hello gophers”! Este atât de simplu: construim GopherJS – îl lansăm în browser – totul funcționează!
Ce ai în acest moment? Legături
Există legături pentru toate cadrele js populare:
- JQuery;
- Angular.js;
- D3.js pentru trasarea și lucrul cu date mari;
- React.js;
- VueJS;
- există chiar și suport pentru Electron (adică putem deja să scriem aplicații desktop pe Electron);
- iar cel mai amuzant lucru este WebGL (putem face aplicații full-graphic, inclusiv jocuri cu grafică 3D, muzică și toate bunătățile);
- și multe alte legături la toate cadrele și bibliotecile javascript populare.
Cadru
- Există deja un cadru web dezvoltat special pentru GopherJS - Vecty. Acesta este un analog cu drepturi depline al React.js, dar dezvoltat doar în Go, cu specificul GopherJS.
- Există saci de joc (surpriză!). Am găsit cele două cele mai populare:
- Engo;
- Ebiten.
Vă voi arăta câteva exemple despre cum arată și despre ce puteți scrie deja în Go:
Sau această opțiune (nu am putut găsi un shooter 3D, dar poate că există):
Ce ofer?
Acum, industria front-end este într-o astfel de stare încât toate limbile care au strigat anterior din Javascript se vor grăbi acolo. Acum totul va fi compilat în „Asambluri web”. De ce avem nevoie pentru a ne ocupa locul cuvenit acolo ca Gophers?
Go a presupus în mod tradițional că este un limbaj de programare System și practic nu există biblioteci pentru a lucra cu UI. Există ceva, dar este pe jumătate abandonat, pe jumătate nefuncțional.
Și acum este o șansă bună de a crea biblioteci UI în Go care vor rula pe GopherJS! În sfârșit poți să-ți scrii propriul cadru! Acesta este momentul în care poți scrie un cadru, acesta va fi unul dintre primele și va primi adoptarea timpurie, iar tu vei fi o vedetă (dacă este un cadru bun).
Puteți adapta o mulțime de pachete diferite care sunt deja în ecosistemul Go la specificul browserului (de exemplu, Motorul de șabloane). Vor funcționa deja, puteți face legături convenabile, astfel încât să puteți reda cu ușurință conținutul direct în browser. În plus, poți realiza, de exemplu, un serviciu care poate reda același lucru pe server și pe front-end, folosind același cod - tot ce le place dezvoltatorilor front-end (doar acum în Go).
Poți scrie un joc! Doar pentru distractie...
Atât am vrut să spun.
întrebări
Întrebare (denumită în continuare Q): – Scriu în Go sau Js?
AG: – Scrii rutine, canale, structuri, încorporare – totul în Go... Te abonezi la un eveniment, treci o funcție acolo.
ÎN: – Așa că scriu în Js „gol”?
AG: – Nu, scrieți ca în Go și vă conectați la API-ul browserului (API-ul nu s-a schimbat). Puteți scrie propriile legături, astfel încât mesajele să fie trimise către canal - nu este dificil.
ÎN: – Dar mobilul?
AG: – Am văzut cu siguranță: există legături pentru patch-ul Cordova pe care îl rulează Js. În React Native - nu știu; poate că există, poate nu (nu m-a interesat în mod deosebit). Motorul de joc N-go acceptă ambele aplicații mobile - atât iOS, cât și Android.
ÎN: – Întrebare despre Web Assembly. Se ocupă din ce în ce mai mult spațiu, în ciuda compresiei și a „zippingului”... Nu vom ucide lumea front-end în acest fel și mai mult?
AG: – Web Assembly este un format binar, iar binarul în mod implicit nu poate fi în versiunea finală mai mult decât text... Sunteți atras de timpul de execuție, dar acest lucru este același cu tragerea bibliotecii standard Javascript atunci când nu este acolo, așa că folosește niște Lodash. Nu știu cât ia Lodash.
ÎN: – Evident, mai puțin decât timpul de rulare...
AG: – În Javascript „pur”?
ÎN: - Da. Îl comprimăm înainte de a-l trimite...
AG: – Dar acesta este text... În general, un megaoctet pare mult, dar asta-i tot (aveți întreaga durată de rulare). Apoi, scrieți propria dvs. logică de afaceri, care vă va crește binarul cu 1%. Până acum, nu văd asta uciderea front-end-ului. Mai mult, Web Assembly va funcționa mai rapid decât Javascript din motivul evident - nu trebuie să fie analizat.
ÎN: – Acesta este încă un punct controversat... Nu există încă nicio implementare de referință a „Vasma” (Asamblare Web), astfel încât să se poată judeca fără ambiguitate. Conceptual, da: înțelegem cu toții că binarul ar trebui să fie mai rapid, dar implementarea actuală a aceluiași V8 este foarte eficientă.
AG: - Da.
ÎN: – Compilarea acolo funcționează foarte bine și nu este un fapt că va exista un mare avantaj.
AG: – Web Assembly este făcut și de băieți mari.
ÎN: – Mi se pare că este încă greu să judeci Web Assembly. Au existat conversații de mulți ani, dar sunt puține realizări care pot fi simțite.
AG: - Pot fi. Vom vedea.
ÎN: – Nu avem probleme pe backend... Poate ar trebui să lăsăm aceste probleme pe front-end? De ce să mergi acolo?
AG: – Trebuie să menținem un personal de lucrători din prima linie.
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com