Kyiv Go Meetup Mai 2018:
Moderator: – Hallo zusammen! Vielen Dank, dass ihr hier seid! Heute haben wir zwei offizielle Sprecher – Alexej und Wanja. Es werden noch zwei weitere sprechen, wenn wir genug Zeit haben. Der erste Sprecher ist Alexej Gratschjow, der uns über GopherJS erzählen wird.
Alexej Gratschjow (im Folgenden – AG): – Ich bin Go-Entwickler und schreibe Web-Services in Go. Manchmal komme ich mit dem Frontend in Berührung, manchmal muss ich da handgreiflich eingreifen. Ich möchte über meine Erfahrungen und Forschungen zu Go im Frontend berichten.
Die Legende ist folgende: Zuerst sprechen wir darüber, warum wir Go im Frontend ausführen möchten, dann besprechen wir, wie dies möglich ist. Es gibt zwei Wege – Web Assembly und GopherJS. Wir werden uns ansehen, in welchem Zustand sich diese Lösungen befinden und was man damit machen kann.
Was ist falsch am Frontend?
Sind wir uns alle einig, dass am Frontend alles gut ist?
Zu wenig Tests? Lange Build-Zeiten? Ö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 während meiner Arbeit konfrontiert war, und erklären, wie sie gelöst werden.
Ein Typsystem kann man in Javascript kaum als solches bezeichnen – es gibt Strings, die den Typ eines Objekts darstellen, aber das hat tatsächlich nichts mit Typen zu tun. Dieses Problem wird in TypeScript (einer Erweiterung von Javascript) und Flow (einem statischen Typ-Prüfer in Javascript) gelöst. Tatsächlich hat das Frontend bereits das Problem eines schlechten Typsystems in Javascript gelöst.
Eine Standardbibliothek gibt es im Browser nicht wirklich – es gibt einige eingebaute Objekte und „magische“ Funktionen in den Browsern. Aber in Javascript als solchem fehlt eine Standardbibliothek. Dieses Problem wurde einmal von jQuery gelöst (alle verwendeten jQuery mit all seinen Prototypen, Helfern und Funktionen, die für die Arbeit benötigt werden). Heute verwendet jeder Lodash:
Callback-Hölle. Ich denke, jeder hat vor etwa 5 Jahren Javascript-Code gesehen, der wie „Nudeln“ aus einem unglaublichen Gewirr von Callbacks aussah. Dieses Problem wurde jetzt gelöst (mit der Einführung von ES-15 oder ES-16), es wurden Promises in Javascript hinzugefügt und alle konnten für eine Zeit wieder leichter atmen.
Bis die Promises-Hölle kam… Ich weiß nicht, wie die Frontend-Industrie es schafft, aber sie treiben sich ständig in seltsame Abgründe. Sie haben sogar in den „Promises“ eine Hölle geschafft. Später wurde dieses Problem gelöst, indem ein neuer Primitiv hinzugefügt wurde – async/await:
Mit der Asynchronität ist das Problem gelöst. Async/await ist ein ziemlich beliebtes Konzept in verschiedenen Programmiersprachen. In Python und anderen Sprachen wird dieser Ansatz verwendet - er ist ziemlich gut. Das Problem ist gelöst.
Welches Problem ist ungelöst? Die exponentiell steigende Komplexität von Frameworks, die Schwierigkeit des Ökosystems und der eigentlichen Programme.
- Die Syntax von Javascript ist etwas seltsam. Wir alle kennen die Schwierigkeiten beim Zusammenfügen von Arrays und Objekten und andere Besonderheiten.
- Javascript ist multiparadigmatisch. Genau jetzt ist es ein besonders relevantes System, wenn das Ökosystem sehr groß ist:
- alle schreiben in verschiedenen Stilen – die einen schreiben strukturiert, die anderen funktional, verschiedene Entwickler schreiben unterschiedlich;
- aus verschiedenen Paketen kommen unterschiedliche Paradigmen, wenn Sie verschiedene Pakete verwenden;
- es gibt sehr viel ‚Spaß‘ mit funktionaler Programmierung in Javascript – es ist eine Bibliothek namens rambda erschienen und jetzt kann niemand mehr die in dieser Bibliothek geschriebenen Programme lesen.
- Das alles hat einen großen Einfluss auf das Ökosystem, und es ist unglaublich gewachsen. Pakete sind untereinander inkompatibel: einige basieren auf Promises, andere auf async/await, wieder andere auf Callbacks. Außerdem wird auch in verschiedenen Paradigmen geschrieben!
- Das führt dazu, dass das Projekt schwer zu warten ist. Es ist schwierig, einen Bug zu finden, wenn Sie den Code nicht lesen können.
Was ist Web Assembly?
Die talentierten Leute von der Mozilla Foundation und mehreren anderen Unternehmen haben so etwas wie Web Assembly erfunden. Was ist das?
- Es ist eine im Browser integrierte virtuelle Maschine, die ein binäres Format unterstützt.
- Binarprogramme werden dort ausgeführt, praktisch nativ, das heißt, der Browser muss nicht jedes Mal den gesamten ‚Satz‘ von Javascript-Code parsen.
- Alle Browser haben Unterstützung zugesagt.
- Da es Bytecode ist, kann man einen Compiler für jede Sprache schreiben.
- Die vier Hauptbrowser bieten bereits Unterstützung für Web Assembly.
- Bald erwarten wir native Unterstützung in Go. Eine solche neue Architektur ist bereits hinzugefügt worden: GOARCH=wasm GOOS=js (bald). Soweit ich verstehe, ist sie derzeit nicht funktional, jedoch gibt es eine Erklärung, dass es auf jeden Fall in Go kommen wird.
Was ist jetzt zu tun? GopherJS
Solange wir keine Unterstützung für Web Assembly haben, gibt es einen Transpiler namens GopherJS.
- Go-Code 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 in allem läuft, was auch immer).
- Es gibt Unterstützung für fast alles, was in Go vorhanden ist, einschließlich Goroutinen und Kanälen … – alles, was wir so lieben und kennen.
- Fast die gesamte Standardbibliothek wird unterstützt, mit Ausnahme der Pakete, deren Unterstützung im Browser keinen Sinn macht: syscall, net-Interaktionen (es gibt einen net/http-Client, aber keinen Server, und der Client wird über XMLHttpRequest emuliert). Insgesamt ist die gesamte Standardbibliothek verfügbar – hier ist sie im Browser, hier ist die stdlib Go, die wir lieben.
- Das gesamte Paket-Ökosystem in Go, alle Drittanbieter-Lösungen (Template-Engines usw.) können mit GopherJS kompiliert und im Browser ausgeführt werden.
GopherJS zu bekommen ist ganz einfach – es ist ein normales Go-Paket. Wir machen go get, und wir haben den Befehl GopherJS, um die Anwendung zu bauen:
So ein kleines Hello World…
…Eine gewöhnliche Go-Anwendung, ein gewöhnliches fmt-Paket der Standardbibliothek und Binding Js, um auf die API des Browsers zuzugreifen. Println wird schließlich in ein Console Log umgewandelt und der Browser wird „Hello gophers!“ ausgeben! So einfach: wir machen GopherJS build – starten im Browser – alles funktioniert!
Was ist derzeit verfügbar? Bindings
Es gibt Bindings für alle beliebten JS-Frameworks:
- JQuery;
- Angular.js;
- D3.js für Diagramme und die Arbeit mit großen Daten;
- React.js;
- VueJS;
- es gibt sogar Unterstützung für Electron (d.h. wir können bereits jetzt Desktop-Anwendungen mit „Electron“ schreiben);
- und das Beste – es ist WebGL (wir können vollgrafische Anwendungen erstellen, einschließlich Spielen mit 3D-Grafik, Musik und allen Vorzügen);
- und sehr viele andere Bindings für alle beliebten JavaScript-Frameworks und -Bibliotheken.
Framework
- Es gibt bereits ein speziell für GopherJS entwickeltes Web-Framework – Vecty. Dies ist ein vollwertiger Analogon zu React.js, jedoch auf Go entwickelt, mit der Spezifik GopherJS.
- Es gibt sogar Spiel-Engines (überraschenderweise!). Ich habe zwei der beliebtesten gefunden:
- Engo;
- Ebiten.
Ich werde ein paar Beispiele zeigen, wie das aussieht und was man bereits jetzt in Go schreiben kann:
Oder so eine Variante (ich habe keinen 3D-Shooter gefunden, aber vielleicht gibt es einen):
Was schlage ich vor?
Aktuell befindet sich die Frontend-Industrie in einem Zustand, wo alle Sprachen, die zuvor über JavaScript geklagt haben, dort einströmen werden. Jetzt werden alle in „WebAssembly“ kompiliert. Was brauchen wir, um dort als „Gopher“ einen angemessenen Platz einzunehmen?
In Go geht man traditionell davon aus, dass es sich um eine Systemprogrammiersprache handelt, und es gibt praktisch keine Bibliotheken für die Arbeit mit der Benutzeroberfläche. Es gibt etwas, aber es ist halb aufgegeben, halb nicht funktional.
Und hier ist eine gute Gelegenheit, UI-Bibliotheken in Go zu erstellen, die auf GopherJS basieren! Man kann endlich sein eigenes Framework schreiben! Die Zeit ist gekommen, ein Framework zu entwickeln, und es wird eines der ersten sein und frühe Anpassung erhalten, und Sie werden zum Star (wenn es ein gutes Framework wird).
Man kann eine Vielzahl unterschiedlicher Pakete, die bereits im Go-Ökosystem vorhanden sind, an die spezifische Browserumgebung anpassen (zum Beispiel Template-Engines). Diese funktionieren bereits, man kann praktische Wrapper erstellen, um Inhalte direkt im Browser einfach zu rendern. Außerdem kann man beispielsweise einen Service entwickeln, der dasselbe sowohl auf dem Server als auch im Frontend rendert, indem er denselben Code verwendet – ganz so, wie es Frontend-Entwickler gerne haben (aber jetzt in Go).
Man kann ein Spiel schreiben! Nur zum Spaß...
Das ist alles von meiner Seite.
Fragen
Frage (im Folgenden – F): – Schreibe ich in Go oder in Js?
AG: – Du schreibst in Go, Routinen, Kanäle, Strukturen, Embedding – alles... Du abonnierst ein Ereignis und übergibst eine Funktion.
Frage: – Also schreibe ich in „purem“ Js?
AG: – Nein, du schreibst gewissermaßen in Go und verbindest dich mit der API des Browsers (die API hat sich dabei nicht geändert). Du kannst deine eigenen Wrapper schreiben, damit Nachrichten in den Kanal kommen – das ist nicht schwer.
Frage: – Was ist mit Mobilgeräten?
AG: – Ich habe definitiv gesehen: Es gibt Bindungen für das Cordova-Patch, das Js ausführt. Bei React Native weiß ich nicht; vielleicht gibt es sie, vielleicht nicht (ich habe mich nicht besonders dafür interessiert). Die Spiel-Engine N-go unterstützt auch mobile Anwendungen – sowohl iOS als auch Android.
Frage: – Frage zu Web Assembly. Der Speicherbedarf wächst, trotz der Komprimierung, der „Zip-Datei“... Werden wir dadurch die Frontend-Welt nicht noch mehr schädigen?
AG: – Web Assembly ist ein binäres Format, und binär kann standardmäßig in der endgültigen Version nicht größer sein als Text... Du meinst das Runtime-Problem, aber das ist dasselbe, wie wenn du die Standardbibliothek von Javascript einbindest, wenn sie nicht vorhanden ist, weshalb wir irgendein Lodash verwenden. Ich weiß nicht, wie viel Lodash benötigt.
Frage: – Deutlich weniger als das Runtime...
AG: – In „purem“ Javascript?
Frage: – Ja. Wir komprimieren es, bevor wir es versenden...
AG: – Aber das ist doch ein Text… Im Allgemeinen sind Megabyte relativ viel, aber das ist alles (du hast deine gesamte Laufzeit). Dann schreibst du deine Geschäftslogik, die dein Binary um 1 % vergrößert. Bisher sehe ich nicht, dass dies das Frontend beeinträchtigt. Zumal Web Assembly schneller arbeiten wird als Javascript, aus dem offensichtlichen Grund – es muss nicht geparst werden.
Frage: – Ein noch strittiger Punkt… Es gibt noch keine definitive Implementierung von „Wasma“ (Web Assembly), um eindeutig urteilen zu können. Konzeptuell – ja: Wir alle verstehen, dass das Binary schneller sein sollte, aber die aktuelle Implementierung von V8 ist sehr effizient.
AG: – Ja.
Frage: – Die Kompilierung funktioniert dort wirklich sehr gut und es ist nicht sicher, dass es einen großen Vorteil geben wird.
AG: – Web Assembly wird auch von großen Unternehmen entwickelt.
Frage: – Im Moment erscheint es mir noch schwierig, über Web Assembly zu urteilen. Seit Jahren wird darüber gesprochen, aber es gibt nur wenige reale Fortschritte, die man anfassen kann.
AG: – Möglicherweise. Wir werden sehen.
Frage: – Wir haben keine Probleme im Backend… Vielleicht sollten wir diese Probleme im Frontend belassen? Warum sollten wir dort eingreifen?
AG: – Wir müssen ein Team von Frontend-Entwicklern beschäftigen.
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 Freunden empfehlen, , ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).
Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie
Quelle: habr.com
