Kyiv Go Meetup Mai 2018:
Moderator: â Hallo zusammen! Vielen Dank, dass Sie hier sind! Heute haben wir zwei offizielle Redner â Alex und Ivan. Wenn wir Zeit haben, gibt es noch zwei weitere. Unser erster Redner ist Alexey Grachev, der uns ĂŒber GopherJS berichten wird.
Alexey Grachev (im Folgenden â AG): â Ich bin Go-Entwickler und schreibe Webservices in Go. Manchmal muss ich mich mit dem Frontend befassen und da selbst Hand anlegen. Ich möchte Ihnen von meinen Erfahrungen und Untersuchungen zur Nutzung von Go im Frontend berichten.
Die Legende ist folgende: Zuerst sprechen wir darĂŒber, warum wir Go im Frontend einsetzen möchten, danach erlĂ€utern wir, wie das möglich ist. Es gibt zwei Wege â Web Assembly und GopherJS. Wir schauen uns an, in welchem Zustand sich diese Lösungen befinden und was man damit tun kann.
Was stimmt nicht mit dem Frontend?
Sind wir uns alle einig, dass alles gut mit dem Frontend ist?
Wenig Tests? Langsame Builds? Ăkosystem? Gut.
Was das Frontend betrifft, gefÀllt mir ein Zitat von einem der Frontend-Entwickler in seinem Buch:
In Javascript gibt es kein Typsystem. Jetzt werde ich die Probleme benennen, mit denen ich im Laufe meiner Arbeit konfrontiert war, und erklÀren, wie man sie löst.
Das Typsystem kann man in JavaScript eigentlich nicht als solches bezeichnen â es gibt Strings, die den Typ eines Objekts anzeigen, aber tatsĂ€chlich haben sie mit Typen nichts zu tun. Dieses Problem wurde in TypeScript (eine Erweiterung von JavaScript) und Flow (einem statischen TypprĂŒfer fĂŒr JavaScript) gelöst. TatsĂ€chlich hat das Frontend die Probleme mit dem mangelhaften Typsystem in JavaScript mittlerweile angegangen.
Eine Standardbibliothek im Browser gibt es nicht wirklich â es existieren einige eingebaute Objekte und "magische" Funktionen in den Browsern. Aber in Javascript als solches fehlt eine Standardbibliothek. Dieses Problem wurde frĂŒher durch jQuery gelöst (jeder verwendete jQuery mit allen Prototypen, Helpern und Funktionen, die fĂŒr die Arbeit notwendig sind). Heute verwendet man stattdessen Lodash:
Callback-Hölle. Ich denke, jeder hat vor etwa 5 Jahren JavaScript-Code gesehen, der wie ein "Nudelgericht" aus einem unglaublichen Durcheinander von Callback-Funktionen aussah. Diese Problematik wurde jetzt mit der EinfĂŒhrung von ES-15 oder ES-16 gelöst, da Promises zu JavaScript hinzugefĂŒgt wurden, was allen fĂŒr eine gewisse Zeit das Leben erleichtert hat.
Bis jetzt hat Promice hell noch nicht erreicht... Ich weiĂ nicht, wie es die Frontend-Industrie schafft, aber sie geraten stĂ€ndig in merkwĂŒrdige AbgrĂŒnde. Sie haben es sogar bei "Promises" geschafft, die Hölle zu erschaffen. Dann haben sie beschlossen, dieses Problem zu lösen, indem sie einen neuen Primitivtyp â async/await â hinzugefĂŒgt haben:
Mit AsynchronitĂ€t ist das Problem gelöst. Async/await ist ein recht populĂ€rer Primitivtyp in verschiedenen Sprachen. In Python und anderen gibt es einen solchen Ansatz â er funktioniert ziemlich gut. Das Problem ist gelöst.
Welches Problem bleibt ungelöst? Die geometrisch wachsende KomplexitĂ€t von Frameworks, die KomplexitĂ€t des Ăkosystems und der Software selbst.
- Die Syntax von JavaScript ist etwas eigenartig. Wir alle kennen die Probleme beim ZusammenfĂŒgen von Arrays und Objekten sowie andere KuriositĂ€ten.
- JavaScript ist multiparadigmatisch. Dies ist jetzt besonders relevant, da das Ăkosystem sehr groĂ ist:
- alle schreiben in unterschiedlichen Stilen â manche schreiben strukturell, andere funktional, verschiedene Entwickler schreiben unterschiedlich;
- aus verschiedenen Paketen resultieren unterschiedliche Paradigmen, wenn Sie verschiedene Pakete verwenden;
- Es gibt eine Menge an âSpaĂâ mit funktionaler Programmierung in JavaScript â es ist eine Bibliothek namens Rambda erschienen und jetzt kann niemand mehr Programme lesen, die mit dieser Bibliothek geschrieben wurden.
- Das hat einen groĂen Einfluss auf das Ăkosystem und es hat sich unglaublich weiterentwickelt. Die Pakete sind untereinander inkompatibel: manche basieren auf Promises, andere auf async/await, manche wiederum auf Callbacks. Und sie werden sogar in verschiedenen Paradigmen geschrieben!
- Das fĂŒhrt dazu, dass das Projekt schwer zu pflegen ist. Es ist schwierig, einen Bug zu finden, wenn du den Code nicht lesen kannst.
Was ist Web Assembly?
Die tollen Leute von der Mozilla Foundation und mehreren anderen Unternehmen haben etwas erfunden, das Web Assembly genannt wird. Was ist das?
- Es handelt sich um eine im Browser integrierte virtuelle Maschine, die ein binĂ€res Format unterstĂŒtzt.
- Binares Programm wird dort ausgefĂŒhrt, praktisch nativ, das heiĂt, der Browser muss nicht jedes Mal den gesamten âNudelnâ-JavaScript-Code parsen.
- Alle Browser haben ihre UnterstĂŒtzung angekĂŒndigt.
- Da dies Bytecode ist, kann man einen Compiler fĂŒr jede Sprache schreiben.
- Die vier groĂen Browser sind bereits mit UnterstĂŒtzung fĂŒr Web Assembly ausgestattet.
- Bald erwarten wir nativ UnterstĂŒtzung in Go. Diese neue Architektur ist bereits hinzugefĂŒgt: GOARCH=wasm GOOS=js (bald). Soweit ich verstehe, ist sie aktuell nicht funktionsfĂ€hig, aber es gibt eine Aussage, dass dies definitiv in Go kommen wird.
Was kann ich jetzt tun? GopherJS
Aktuell haben wir keine UnterstĂŒtzung fĂŒr Web Assembly, aber es gibt einen Transpiler namens GopherJS.
- Code in Go wird in âreinesâ Javascript transpiliert.
- Es lĂ€uft in allen Browsern â es gibt keine neuen Funktionen, die nur von modernen Browsern unterstĂŒtzt werden (das ist Vanilla JS, das ĂŒberall lĂ€uft).
- So gut wie alles, was in Go vorhanden ist, wird unterstĂŒtzt, einschlieĂlich Goroutinen und KanĂ€len⊠â alles, was wir so lieben und kennen.
- Fast die gesamte Standardbibliothek wird unterstĂŒtzt, mit Ausnahme der Pakete, die im Browser keinen Sinn machen: syscall, net-Interaktionen (es gibt einen net/http-Client, aber keinen Server, und der Client wird ĂŒber XMLHttpRequest emuliert). Im Allgemeinen ist die gesamte Standardbibliothek verfĂŒgbar â hier ist sie im Browser, hier ist die stdlib Go, die wir lieben.
- Das gesamte Ăkosystem von Go-Paketen, alle Drittanbieterlösungen (Templating usw.) können mit GopherJS kompiliert und im Browser ausgefĂŒhrt werden.
Es ist ganz einfach, GopherJS zu erhalten â es handelt sich um ein gewöhnliches Go-Paket. Machen Sie ein âgo getâ, und Sie haben das GopherJS-Tool, um Ihre Anwendung zu kompilieren:
Hier ist ein kleines Hello World...
...Eine normale Go-Anwendung, ein ganz gewöhnliches fmt-Paket aus der Standardbibliothek und die Binding-Tools, um auf die Browser-API zuzugreifen. Das Println wird schlieĂlich in ein Console Log umgewandelt, und der Browser zeigt âHello gophersâ an! So einfach: Wir machen GopherJS build â starten im Browser â und alles funktioniert!
Was gibt es bisher? Bindings
Es gibt Bindings fĂŒr alle gĂ€ngigen JS-Frameworks:
- JQuery;
- Angular.js;
- D3.js fĂŒr Diagramme und die Arbeit mit groĂen Datenmengen;
- React.js;
- VueJS;
- es gibt sogar UnterstĂŒtzung fĂŒr Electron (das bedeutet, dass wir bereits jetzt Desktop-Anwendungen mit âElectronâ entwickeln können);
- und das Lustigste â es ist WebGL (wir können photorealistische Anwendungen erstellen, einschlieĂlich Spiele mit 3D-Grafik, Musik und allen anderen Extras);
- und viele weitere Bindings fĂŒr alle gĂ€ngigen JavaScript-Frameworks und -Bibliotheken.
Framework
- Es gibt bereits ein speziell fĂŒr GopherJS entwickeltes Web-Framework â Vecty. Es ist ein vollstĂ€ndiges Ăquivalent zu React.js, jedoch auf Go basierend, mit den spezifischen Eigenschaften von GopherJS.
- Es gibt sogar SpielesĂ€cke (ĂŒberraschend!). Ich habe die zwei populĂ€rsten gefunden:
- Engo;
- Ebiten.
Ich möchte Ihnen ein paar Beispiele zeigen, wie das aussieht und was man bereits jetzt in Go schreiben kann:
Oder eine andere Variante (ich habe keinen 3D-Shooter gefunden, aber vielleicht gibt es ihn):
Was schlage ich vor?
Die Frontend-Industrie befindet sich derzeit in einem Zustand, in dem alle Programmiersprachen, die zuvor ĂŒber Javascript geklagt haben, nun auf den Markt drĂ€ngen. Jetzt werden alle in âWebAssemblyâ kompiliert. Was brauchen wir, um dort einen angemessenen Platz als âGopherâ einzunehmen?
Es hat sich traditionell gezeigt, dass Go eine Systemprogrammiersprache ist und es praktisch keine Bibliotheken fĂŒr die Arbeit mit UI gibt. Es gibt einige, aber sie sind zur HĂ€lfte veraltet und zur HĂ€lfte nicht funktional.
Und jetzt â eine hervorragende Gelegenheit, UI-Bibliotheken in Go zu entwickeln, die auf GopherJS ausgefĂŒhrt werden! Endlich kann man sein eigenes Framework schreiben! Es ist die Zeit gekommen, ein Framework zu entwickeln, das eines der ersten sein wird, sich frĂŒh anpassen wird und Sie zur BerĂŒhmtheit machen kann (wenn es ein gutes Framework ist).
Es lassen sich zahlreiche verschiedene Pakete, die bereits im Go-Ăkosystem verfĂŒgbar sind, an die Besonderheiten des Browsers anpassen (zum Beispiel Template-Engine). Sie funktionieren bereits, zudem kann man nĂŒtzliche Wrapper erstellen, um Inhalte direkt im Browser einfach zu rendern. AuĂerdem lĂ€sst sich beispielsweise ein Service erstellen, der dasselbe sowohl auf dem Server als auch im Frontend rendert, und dabei denselben Code verwendet â genau so, wie es Frontend-Entwickler mögen (nun eben auf Go).
Man könnte ein Spiel schreiben! Just for funâŠ
Das war's von meiner Seite.
Fragen
Frage (im Folgenden â F): â Schreibe ich in Go oder in Js?
AG: â Du schreibst in Go-Routinen, KanĂ€len, Strukturen, Embedding â alles... Du abonnierst ein Event, ĂŒbergibst eine Funktion.
Frage: â Das heiĂt, ich schreibe quasi in âreinemâ Js?
AG: â Nein, du schreibst gewissermaĂen in Go und greifst auf die Browser-API zu (die API hat sich dabei nicht verĂ€ndert). Du kannst deine eigenen Wrapper schreiben, damit Nachrichten in den Kanal gelangen â das ist ja nicht kompliziert.
Frage: â Wie sieht es mit MobilgerĂ€ten aus?
AG: â Ich habe auf jeden Fall gesehen, dass es Bindings fĂŒr das Cordova-Patch gibt, das Js ausfĂŒhrt. Bei React Native â ich weiĂ nicht; vielleicht gibt es welche, vielleicht nicht (darum habe ich mich nicht wirklich gekĂŒmmert). Die Game-Engine N-go unterstĂŒtzt auch mobile Anwendungen â sowohl iOS als auch Android.
Frage: â Frage zu Web Assembly. Immer mehr Platz wird beansprucht, trotz der Komprimierung, der "Zip-Datei"... Töten wir dadurch die Welt des Frontends nicht noch mehr?
AG: â Web Assembly ist ein binĂ€res Format, und binĂ€r kann per Default in der endgĂŒltigen Version nicht mehr sein als Text⊠Ihr strebt nach Runtime, aber das ist dasselbe, wie eine Standard-Javascript-Bibliothek anzuziehen, wenn sie nicht vorhanden ist, deshalb verwenden wir etwas wie Lodash. Ich weiĂ nicht, wie viel Lodash benötigt.
Frage: â Offensichtlich weniger als Runtime...
AG: â Auf "purem" Javascript?
Frage: â Ja. Wir komprimieren es, bevor wir es senden...
AG: â Aber das ist doch Text... Im Allgemeinen ist ein Megabyte viel, aber das ist alles (du hast deine gesamte Runtime). Dann schreibst du deine Business-Logik, die deinen Binary um 1 % erhöht. Bisher sehe ich nicht, dass es das Frontend ruiniert. AuĂerdem wird Web Assembly schneller arbeiten als Javascript aus einem offensichtlichen Grund â es muss nicht geparst werden.
Frage: â Das ist derzeit ein strittiger Punkt... Es gibt noch keine definitive Implementierung von "Wasm" (Web Assembly), um ein eindeutiges Urteil abgeben zu können. Konzeptuell â ja: Wir alle verstehen, dass binĂ€r schneller sein sollte, aber die aktuelle Implementierung von V8 ist sehr effizient.
AG: â Ja.
Frage: â Die Kompilierung funktioniert wirklich groĂartig dort, und es ist nicht sicher, dass es einen groĂen Vorteil geben wird.
AG: â Auch groĂe Unternehmen nutzen Web Assembly.
Frage: â Im Moment scheint es mir noch schwierig zu sein, Web Assembly zu beurteilen. Es gibt schon seit Jahren Diskussionen, aber die tatsĂ€chlichen greifbaren Erfolge sind eher spĂ€rlich.
AG: â Vielleicht. Wir werden sehen.
Frage: â Wir haben keine Probleme im Backend... Vielleicht sollten wir diese Probleme im Frontend belassen? Warum dort eingreifen?
AG: â Man muss ein Team von Frontend-Entwicklern halten.
Ein wenig Werbung đ
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? UnterstĂŒtzen Sie uns, indem Sie eine Bestellung aufgeben oder uns Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir fĂŒr Sie entwickelt haben: (VerfĂŒgbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 â 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â ab 99 $! Lesen Sie darĂŒber
Quelle: habr.com
