Meetup-ul Go din Kiev, mai 2018:
Moderator: – Bună ziua tuturor! Vă mulțumesc că sunteți aici! Astăzi avem doi vorbitori oficiali – Alex și Vania. Vor mai fi încă doi, dacă avem timp. Primul vorbitor este Alexey Grachev, care ne va vorbi despre GopherJS.
Alexey Grachev (din acest moment – AG): – Eu sunt dezvoltator Go și scriu servicii web în Go. Uneori trebuie să mă ocup de frontend, uneori trebuie să intervin manual acolo. Vreau să vă împărtășesc experiența și cercetările mele despre Go în frontend.
Legenda este că mai întâi vom discuta despre de ce vrem să rulăm Go în frontend, apoi vom discuta despre cum se poate face acest lucru. Există două căi – Web Assembly și GopherJS. Să vedem în ce stare sunt aceste soluții și ce putem face.
Ce nu este în regulă cu frontend-ul?
Toată lumea este de acord că totul este bine cu frontend-ul?
Nu sunt suficiente teste? Compilare lentă? Ecologie? Bine.
În legătură cu frontend-ul, îmi place o citat spus de unul dintre dezvoltatorii frontend în cartea sa:
În Javascript nu există un sistem de tipuri. Acum voi numi problemele cu care m-am confruntat în timpul muncii și voi explica cum sunt rezolvate.
Este greu de numit un sistem de tipuri în Javascript – există șiruri de caractere care reprezintă tipul unui obiect, dar de fapt nu au legătură cu tipurile. Această problemă a fost rezolvată în TypeScript (un suprastructură pe lângă Javascript) și Flow (un static-checker de tipuri în Javascript). Practic, frontend-ul a ajuns deja la soluția problemei sistemului de tipuri slab în Javascript.
Nu există o bibliotecă standard în browser, așa cum există în mod obișnuit – există câteva obiecte încorporate și funcții „magice” în browsere. Dar în Javascript, biblioteca standard lipsește. Această problemă a fost cândva rezolvată de jQuery (toată lumea folosea jQuery cu toate prototipurile, helper-urile, funcțiile necesare pentru a funcționa). Acum, toată lumea folosește Lodash:
Callback hell. Cred că toată lumea a văzut cod Javascript acum aproximativ 5 ani, iar acesta arăta ca o „tăvălug” dintr-o rețea incredibilă de callback-uri. Acum, această problemă a fost rezolvată (odată cu lansarea ES-15 sau ES-16), au fost adăugate promisiuni (promises) în Javascript și tuturor le-a fost mai ușor pentru o vreme.
Până nu a venit Promice hell... Nu știu cum reușește industria frontend, dar tot timpul se bagă în niște situații ciudate. Au reușit să facă hell și cu „promisiunile”. Apoi au rezolvat această problemă, adăugând un nou primitiv – async/await:
Problema cu asynchronicitatea este rezolvată. Async/await este un primitiv destul de popular în diferite limbaje. În Python și în altele există o astfel de abordare – este destul de bună. Problema este soluționată.
Ce problemă nu este rezolvată? Complexitatea ecosistemului și a framework-urilor, care crește exponențial, precum și programarea în sine.
- Sintaxa Javascript este puțin ciudată. Cu toții știm de problemele cu adunarea unui array și a unui obiect și alte capcane.
- Javascript este multiparadigmatic. Acum este un sistem mai ales necesar, deoarece ecosistemul este foarte mare:
- toată lumea scrie în stiluri diferite – unii scriu în mod structural, alții funcțional, diferiți dezvoltatori scriu diferit;
- din diferite pachete (packages) vin paradigme diferite, când folosești diferite pachete;
- există foarte multă «distracție» cu programarea funcțională în Javascript – a apărut biblioteca ramda și acum nimeni nu poate citi programele scrise în această bibliotecă.
- Toate acestea aduc un impact major asupra ecosistemului, care a crescut incredibil. Pachetele nu sunt compatibile între ele: unii folosesc promisiuni, alții async/await, alții callback-uri. Totodată, se scrie în diferite paradigme!
- Aceasta duce la dificultăți în menținerea proiectului. E greu să găsești un bug dacă nu poți citi codul.
Ce este Web Assembly?
Echipa de la Mozilla Foundation și alte companii au venit cu ceva numit Web Assembly. Ce este asta?
- Este o mașină virtuală încorporată în browser care suportă un format binar.
- Programele binare sunt introduce aici și se execută aproape nativ, adică browserul nu trebuie să parcurgă tot codul javascript de fiecare dată.
- Toate browserele au declarat suport pentru aceasta.
- Deoarece este byte-code, poți scrie un compilator pentru orice limbaj.
- Cele patru browsere principale sunt deja livrate cu suport pentru Web Assembly.
- În curând așteptăm suport nativ în Go. O astfel de nouă arhitectură s-a adăugat deja: GOARCH=wasm GOOS=js (în curând). Până acum, așa cum înțeleg eu, nu este funcțională, dar există o declarație că aceasta va fi cu siguranță disponibilă în Go.
Ce trebuie să facem acum? GopherJS
Până când nu avem suport pentru Web Assembly, există un transpiler numit GopherJS.
- Codul Go este transpilat în Javascript «curat».
- Se rulează în toate browserele – nu conține funcții noi care sunt suportate doar de browsere moderne (acesta este Vanilla JS, care se rulează pe orice fel de platformă).
- Există suport pentru aproape tot ce este în Go, inclusiv goroutine și canale… – tot ce iubim și știm.
- Practically întreaga bibliotecă standard este suportată, cu excepția pachetelor pentru care nu are sens să fie suportate în browser: syscall, interacțiuni de rețea (există client net/http, dar nu și server, iar clientul este emulat prin XMLHttpRequest). În general, întreaga bibliotecă standard este disponibilă – iată-o în browser, iată stdlib Go, pe care o iubim.
- Întreaga ecosistem de pachete în Go, toate soluțiile terțe (șabloane etc.) pot fi compilate folosind GopherJS și rulate în browser.
Obținerea GopherJS este foarte simplă – este un pachet Go obișnuit. Facem go get, și avem comanda GopherJS pentru a construi aplicația:
Iată un mic hello world…
…Un program Go obișnuit, un pachet fmt din biblioteca standard și Binding Js, pentru a accesa API-ul browserului. Println se va transforma în console log, iar browserul va scrie “Hello gophers”! Așa de simplu: facem GopherJS build – îl lansăm în browser – totul funcționează!
Ce avem până acum? Bindings
Există bindings pentru toate framework-urile js populare:
- JQuery;
- Angular.js;
- D3.js pentru crearea de grafice și lucrul cu seturi mari de date;
- React.js;
- VueJS;
- chiar există suport pentru Electron (deci deja putem scrie aplicații desktop pe «Electron»);
- și cel mai amuzant – este WebGL (putem face aplicații poligonale, inclusiv jocuri cu grafică 3D, muzică și toate opțiunile);
- și foarte multe alte bindings pentru toate framework-urile și bibliotecile javascript populare.
Framework
- Există deja un framework web dezvoltat special pentru GopherJS – Vecty. Este un echivalent complet al React.js, dar dezvoltat pe Go, cu specificarea GopherJS.
- Există saci de jocuri (surpriză!). Am găsit două dintre cele mai populare:
- Engo;
- Ebiten.
Voi demonstra câteva exemple, cum arată și ce poate fi deja scris pe Go:
Sau o astfel de variantă (nu am găsit un shooter 3D, dar poate există):
Ce propun?
Industria frontend-ului se află acum într-o stare astfel încât toate limbile care anterior s-au plâns de Javascript vor veni acum. Acum toate vor fi compilează în „Web Assembly”. Ce ne trebuie pentru a ocupa un loc demn acolo ca „gofers”?
În Go, este o tradiție că acesta este un limbaj de programare de sistem, iar practic nu există biblioteci pentru a lucra cu UI. Există câteva, dar sunt pe jumătate abandonate, pe jumătate nefuncționale.
Și iată – o oportunitate bună de a crea biblioteci UI în Go, care vor rula pe GopherJS! În sfârșit, poți scrie propriul tău framework! A venit acea vreme când poți scrie un framework, și va fi unul dintre primele care va primi adaptare timpurie, iar tu vei fi o stea (dacă este un framework bun).
Poți adapta o mulțime de pachete diferite, care există deja în ecosistemul Go, la specificul browser-ului (de exemplu, motor de template). Ele vor funcționa deja; poți face înveliri convenabile pentru a putea reda conținutul direct în browser. În plus, poți crea, de exemplu, un serviciu capabil să redea același lucru pe server și pe front-end, folosind același cod – exact cum îi place dezvoltatorilor front-end (doar că acum în Go).
Poți scrie un joc! Doar pentru distracție…
Asta e tot.
Întrebări
Întrebare (în continuare – Î): – Scriu în Go sau în Js?
AG: – Scrii în Go rutine, canale, structuri, embedding – tot... Te abonezi la eveniment, transmiți o funcție acolo.
M: – Deci, scriu în «gol» Js?
AG: – Nu, scrii cumva în Go și te conectezi la API-ul browser-ului (API-ul nu s-a schimbat). Poți scrie propriile tale înveliri, astfel încât mesajele să ajungă în canal – nu e greu.
M: – Ce zici de mobil?
AG: – Am văzut clar: există binding-uri pentru patch-ul Cordova, care sunt rulate de Js. În React Native – nu știu; poate există, poate nu (nu m-am interesat prea mult). Motorul de joc N-go suportă aplicații mobile – atât iOs, cât și Android.
M: – Întrebare despre Web Assembly. Spațiul ocupat crește tot mai mult, în ciuda comprimării, „zip-erii”... Nu vom distruge astfel lumea front-end-ului și mai mult?
AG: – Web Assembly este un format binar, iar binarul prin default nu poate fi mai mare în versiunea finală decât textul... Te atrage runtime-ul, dar este același lucru cu a trage biblioteca standard Javascript când nu este, de aceea folosim ceva de genul Lodash. Nu știu cât ocupă Lodash.
M: – Cu siguranță mai puțin decât runtime-ul...
AG: – Pe Javascript «curat»?
M: – Da. Îl comprimăm înainte de a-l trimite...
AG: – Dar acesta este un text… În general, un megabyte pare mult, dar este totul (ai tot runtime-ul). Apoi, scrii logica ta de afaceri, care va crește binary-ul cu 1%. Până acum nu văd cum asta ar afecta frontend-ul. În plus, Web Assembly va funcționa mai repede decât Javascript din motive evidente – nu trebuie să fie parsată.
M: – Este un punct de discuție… Nu există încă o implementare de referință a „Vasmă” (Web Assembly) pentru a putea judeca în mod clar. Conceptual – da: toți înțelegem că binary-ul ar trebui să fie mai rapid, dar implementarea actuală a lui V8 este foarte eficientă.
AG: – Da.
M: – Compilarea acolo funcționează într-adevăr foarte bine și nu este garantat că va exista un mare avantaj.
AG: – Web Assembly este dezvoltat și de mari companii.
M: – Până acum, mi se pare că este încă greu de judecat Web Assembly. Au trecut câțiva ani de discuții, dar realizările reale pe care le putem testa sunt puține.
AG: – Poate. Vom vedea.
M: – Nu avem probleme pe backend… Poate ar trebui să lăsăm aceste probleme pe frontend? De ce să intervenim acolo?
AG: – Trebuie să avem un personal de frontend.
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
