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
