Kyiv Go Meetup Mai 2018:
Moderator: - Hallo zusammen! Danke, dass du hier bist! Heute haben wir zwei offizielle Redner – Lyosha und Vanya. Wenn wir genug Zeit haben, werden es noch zwei weitere sein. Der erste Redner ist Alexey Grachev, er wird uns von GopherJS erzählen.
Alexey Grachev (im Folgenden – AG): – Ich bin ein Go-Entwickler und schreibe Webdienste in Go. Manchmal muss man sich mit dem Frontend auseinandersetzen, manchmal muss man manuell hineingehen. Ich möchte über meine Erfahrungen und Forschungen zu Go im Frontend sprechen.
Die Legende lautet: Zuerst werden wir darüber sprechen, warum wir Go im Frontend ausführen wollen, dann werden wir darüber sprechen, wie das gemacht werden kann. Es gibt zwei Möglichkeiten: Web Assembly und GopherJS. Schauen wir uns an, wie der Stand dieser Lösungen ist und was getan werden kann.
Was stimmt mit dem Frontend nicht?
Sind sich alle einig, dass mit dem Frontend alles in Ordnung ist?
Gibt es nicht genügend Tests? Langsamer Aufbau? Ökosystem? Bußgeld.
Bezüglich des Frontends gefällt mir das Zitat, das einer der Frontend-Entwickler in seinem Buch gesagt hat:
Javascript hat kein Typsystem. Nun werde ich die Probleme benennen, auf die ich im Laufe meiner Arbeit gestoßen bin, und erklären, wie sie gelöst werden.
Das Typsystem im Allgemeinen kann in Javascript kaum als Typsystem bezeichnet werden – es gibt Zeilen, die den Typ des Objekts angeben, aber tatsächlich hat dies nichts mit Typen zu tun. Dieses Problem wird in TypeScript (einem Add-on zu Javascript) und Flow (einem statischen Typprüfer in Javascript) gelöst. Tatsächlich hat das Frontend bereits den Punkt erreicht, an dem es das Problem eines fehlerhaften Typsystems in Javascript löst.
Es gibt keine Standardbibliothek im Browser als solche – es gibt einige integrierte Objekte und „magische“ Funktionen in Browsern. Aber in Javascript gibt es keine Standardbibliothek als solche. Dieses Problem wurde bereits einmal von jQuery gelöst (jeder nutzte jQuery mit allen Prototypen, Helfern, Funktionen, die zum Funktionieren nötig waren). Jetzt nutzt jeder Lodash:
Rückruf-Hölle. Ich glaube, jeder hat vor etwa fünf Jahren Javascript-Code gesehen, und er sah aus wie eine „Nudel“ unglaublich komplexer Rückrufe. Jetzt ist dieses Problem gelöst (mit der Veröffentlichung von ES-5 oder ES-15), Versprechen wurden zu Javascript hinzugefügt und jeder kann für eine Weile aufatmen.
Bis die Promice-Hölle kam ... Ich weiß nicht, wie die Front-End-Branche zurechtkommt, aber sie treiben sich immer in einen seltsamen Dschungel. Wir haben es auch geschafft, Versprechen einzuhalten. Dann haben wir dieses Problem gelöst, indem wir ein neues Grundelement hinzugefügt haben – async/await:
Das Problem mit der Asynchronität ist gelöst. Async/await ist in verschiedenen Sprachen ein recht beliebtes Grundelement. Python und andere haben diesen Ansatz – er ist ziemlich gut. Das Problem ist gelöst.
Welches Problem ist nicht gelöst? Die exponentiell zunehmende Komplexität der Frameworks, die Komplexität des Ökosystems und der Programme selbst.
- Die Javascript-Syntax ist etwas seltsam. Wir alle kennen die Probleme beim Hinzufügen eines Arrays und eines Objekts und andere Witze.
- Javascript ist multiparadigmatisch. Dies ist ein besonders dringendes System, da das Ökosystem jetzt sehr groß ist:
- Jeder schreibt in unterschiedlichen Stilen – manche schreiben strukturell, manche funktional, verschiedene Entwickler schreiben auf unterschiedliche Weise;
- aus verschiedenen Paketen, unterschiedliche Paradigmen, wenn Sie unterschiedliche Pakete verwenden;
- Es gibt viel „Spaß“ mit der funktionalen Programmierung in Javasript – die Rambda-Bibliothek ist aufgetaucht und jetzt kann niemand mehr Programme lesen, die in dieser Bibliothek geschrieben sind.
- All dies hat große Auswirkungen auf das Ökosystem und es ist unglaublich gewachsen. Die Pakete sind untereinander inkompatibel: Einige basieren auf Versprechen, andere auf Async/Await und wieder andere auf Rückrufen. Sie schreiben auch in unterschiedlichen Paradigmen!
- Dies macht die Wartung des Projekts schwierig. Es ist schwierig, einen Fehler zu finden, wenn Sie den Code nicht lesen können.
Was ist Webassembly?
Die mutigen Jungs von der Mozilla Foundation und einer Reihe anderer Unternehmen haben sich so etwas wie Web Assembly ausgedacht. Was ist das?
- Dabei handelt es sich um eine im Browser integrierte virtuelle Maschine, die das Binärformat unterstützt.
- Binärprogramme gelangen dorthin und werden fast nativ ausgeführt, das heißt, der Browser muss nicht jedes Mal alle „Nudeln“ des Javascript-Codes analysieren.
- Alle Browser haben ihre Unterstützung erklärt.
- Da es sich um Bytecode handelt, können Sie einen Compiler für jede Sprache schreiben.
- Vier große Browser werden bereits mit Web Assembly-Unterstützung ausgeliefert.
- Wir erwarten bald native Unterstützung in Go. Diese neue Architektur wurde bereits hinzugefügt: GOARCH=wasm GOOS=js (bald). Soweit ich weiß, ist es nicht funktionsfähig, aber es gibt eine Aussage, dass es definitiv in Go sein wird.
Was nun? GopherJS
Obwohl wir Web Assembly nicht unterstützen, gibt es einen Transpiler wie GopherJS.
- Go-Code wird in „reines“ Javascript transpiliert.
- Läuft in allen Browsern – es gibt keine neuen Funktionen, die nur von modernen Browsern unterstützt werden (dies ist Vanilla JS, das auf allem läuft).
- Es gibt Unterstützung für fast alles, was Go hat, einschließlich Goroutinen und Kanälen … alles, was wir so sehr lieben und kennen.
- Fast die gesamte Standardbibliothek wird unterstützt, mit Ausnahme der Pakete, deren Unterstützung im Browser keinen Sinn macht: Syscall, Net Interactions (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 im Browser, hier ist die stdlib von Go, die wir lieben.
- Das gesamte Paket-Ökosystem in Go, alle Lösungen von Drittanbietern (Templating etc.) können mit GopherJS kompiliert und im Browser ausgeführt werden.
GopherJS ist sehr einfach zu bekommen – es ist nur ein normales Go-Paket. Wir gehen get, und wir haben einen GopherJS-Befehl, um die Anwendung zu erstellen:
Das ist so eine kleine Hallo-Welt...
...Ein reguläres Go-Programm, ein reguläres FMT-Paket der Standardbibliothek und Binding Js, um die Browser-API zu erreichen. Println wird schließlich in ein Konsolenprotokoll umgewandelt und der Browser schreibt „Hallo Gophers“! So einfach ist das: Wir erstellen GopherJS – wir starten es im Browser – alles funktioniert!
Was hast du im Moment? Bindungen
Es gibt Bindungen für alle gängigen JS-Frameworks:
- JQuery;
- Angular.js;
- D3.js zum Plotten und Arbeiten mit Big Data;
- React.js;
- VueJS;
- es gibt sogar Unterstützung für Electron (das heißt, wir können bereits Desktop-Anwendungen auf Electron schreiben);
- und das Lustigste ist WebGL (wir können vollgrafische Anwendungen erstellen, einschließlich Spielen mit 3D-Grafiken, Musik und allem Drum und Dran);
- und viele andere Anbindungen an alle gängigen Javascript-Frameworks und -Bibliotheken.
Unser Ansatz
- Es gibt bereits ein speziell für GopherJS entwickeltes Webframework – Vecty. Dies ist ein vollwertiges Analogon von React.js, jedoch nur in Go entwickelt, mit den Besonderheiten von GopherJS.
- Es gibt Wildbeutel (Überraschung!). Am beliebtesten fand ich die beiden:
- Engo;
- Ebiten.
Ich zeige Ihnen ein paar Beispiele, wie es aussieht und was Sie bereits in Go schreiben können:
Oder diese Option (ich konnte keinen 3D-Shooter finden, aber vielleicht existiert er):
Was biete ich an?
Jetzt ist die Front-End-Branche in einem solchen Zustand, dass alle Sprachen, die zuvor aus Javascript hervorgegangen sind, dorthin strömen werden. Nun wird alles zu „Web Assemblies“ kompiliert. Was brauchen wir, um dort unseren rechtmäßigen Platz als Gophers einzunehmen?
Go geht traditionell davon aus, dass es sich um eine Systemprogrammiersprache handelt und es praktisch keine Bibliotheken für die Arbeit mit der Benutzeroberfläche gibt. Es gibt etwas, aber es ist halb verlassen, halb funktionsunfähig.
Und jetzt ist eine gute Gelegenheit, UI-Bibliotheken in Go zu erstellen, die auf GopherJS laufen! Endlich können Sie Ihr eigenes Framework schreiben! Dies ist die Zeit, in der Sie ein Framework schreiben können, und es wird eines der ersten sein und frühzeitig angenommen werden, und Sie werden ein Star sein (wenn es ein gutes Framework ist).
Sie können viele verschiedene Pakete, die bereits im Go-Ökosystem vorhanden sind, an die Besonderheiten des Browsers anpassen (z. B. Template Engine). Sie funktionieren bereits, Sie können praktische Bindungen vornehmen, sodass Sie den Inhalt problemlos direkt im Browser rendern können. Außerdem können Sie beispielsweise einen Dienst erstellen, der mit demselben Code dasselbe auf dem Server und im Front-End rendern kann – alles, was Front-End-Entwicklern gefällt (nur jetzt in Go).
Du kannst ein Spiel schreiben! Nur zum Spaß…
Ich habe alles
Fragen
Frage (im Folgenden als F bezeichnet): – Schreibe ich in Go oder Js?
AG: – Du schreibst Routinen, Kanäle, Strukturen, Einbettung – alles in Go... Du abonnierst ein Event, übergibst dort eine Funktion.
in: – Also schreibe ich in „nacktem“ Js?
AG: – Nein, Sie schreiben wie in Go und stellen eine Verbindung zur Browser-API her (die API hat sich nicht geändert). Sie können Ihre eigenen Bindungen schreiben, damit Nachrichten an den Kanal gesendet werden – das ist nicht schwierig.
in: – Was ist mit Mobilgeräten?
AG: – Ich habe definitiv gesehen: Es gibt Bindungen für den Cordova-Patch, den Js ausführt. In React Native – ich weiß es nicht; Vielleicht gibt es das, vielleicht auch nicht (ich war nicht besonders interessiert). Die N-go-Game-Engine unterstützt beide mobilen Anwendungen – sowohl iOS als auch Android.
in: – Frage zur Webassemblierung. Trotz Komprimierung und „Zippen“ wird immer mehr Platz beansprucht... Werden wir die Frontend-Welt auf diese Weise nicht noch mehr zerstören?
AG: – Web Assembly ist ein Binärformat, und Binärformate können in der endgültigen Version standardmäßig nicht mehr als Text enthalten sein ... Sie fühlen sich zur Laufzeit hingezogen, aber das ist dasselbe, als würde man die Standard-Javascript-Bibliothek herausziehen, wenn sie nicht vorhanden ist, also wir Benutze etwas Lodash. Ich weiß nicht, wie viel Lodash braucht.
in: – Offensichtlich weniger als Laufzeit...
AG: – In „reinem“ Javascript?
in: - Ja. Wir komprimieren es, bevor wir es versenden...
AG: – Aber das ist Text... Im Allgemeinen scheint ein Megabyte viel zu sein, aber das ist alles (Sie haben die gesamte Laufzeit). Als Nächstes schreiben Sie Ihre eigene Geschäftslogik, die Ihre Binärzahl um 1 % erhöht. Bisher sehe ich nicht, dass dadurch das Frontend zerstört wird. Darüber hinaus arbeitet Web Assembly aus dem offensichtlichen Grund schneller als Javascript – es muss nicht analysiert werden.
in: – Dies ist immer noch ein umstrittener Punkt... Es gibt noch keine Referenzimplementierung von „Vasma“ (Web Assembly), so dass man eindeutig urteilen kann. Vom Konzept her ja: Wir alle verstehen, dass Binärdateien schneller sein sollten, aber die aktuelle Implementierung derselben V8 ist sehr effizient.
AG: - Ja.
in: – Die Kompilierung dort funktioniert wirklich sehr gut und es ist keine Tatsache, dass es einen großen Vorteil geben wird.
AG: – Web Assembly wird auch von großen Leuten gemacht.
in: – Es scheint mir immer noch schwierig zu sein, Web Assembly zu beurteilen. Es gibt zwar schon seit vielen Jahren Gespräche, aber wirkliche Erfolge sind kaum zu spüren.
AG: - Vielleicht. Wir werden sehen.
in: – Wir haben keine Probleme im Backend... Vielleicht sollten wir diese Probleme im Frontend belassen? Warum dorthin gehen?
AG: – Wir müssen einen Stab von Mitarbeitern an vorderster Front behalten.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com