Get best of the week

Alexey Grachev: Gehen Sie Frontend

Kyiv Go Meetup Mai 2018:



Gastgeber: - Hallo allerseits! Danke, dass Sie hierher gekommen sind! Heute haben wir zwei offizielle Redner - Lesha und Vanya. Es werden noch zwei sein, wenn wir genug Zeit haben. 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 auf Go. Manchmal muss man sich um das Frontend kümmern, manchmal muss man mit Stiften dorthin klettern. Ich möchte über meine Erfahrungen und Forschungen sprechen.

Die Legende lautet: Zuerst werden wir darüber sprechen, warum wir Go im Front-End ausführen wollen, dann werden wir darüber sprechen, wie dies getan werden kann. Es gibt zwei Möglichkeiten - Web Assembly und GopherJS. Mal sehen, in welchem ​​Zustand diese Entscheidungen sind und was getan werden kann.

Was ist los mit dem Frontend?


Sind sich alle einig, dass mit dem Frontend alles in Ordnung ist?



Gibt es wenige Tests? Langsame Montage? Ökosystem? Gut.

In Bezug auf das Frontend gefällt mir das Zitat, das einer der Frontend-Entwickler in seinem Buch sagte:



Es gibt kein Typensystem in Javascript. Jetzt werde ich die Probleme benennen, auf die ich im Laufe meiner Arbeit gestoßen bin, und erklären, wie sie gelöst werden.

Es ist im Allgemeinen schwierig, ein Typsystem in Javasript als Typsystem zu bezeichnen - es gibt Linien, die den Typ eines Objekts angeben, aber in Wirklichkeit hat es nichts mit Typen zu tun. Dieses Problem wurde in TypeScript (ein Add-On für Javasript) und Flow (statische Prüftypen in Javascript) behoben. Tatsächlich hat das Frontend bereits die Lösung für das Problem eines schlechten Typsystems in Javascript gefunden.



Es gibt keine Standardbibliothek im Browser als solche - es gibt einige eingebaute Objekte und "magische" Funktionen in Browsern. Aber ich habe keine Standardbibliothek in Javascript als solche. Dieses Problem wurde einmal von jQuery gelöst (jeder verwendete jQuery mit allen Prototypen, Helfern und Funktionen, die zum Arbeiten benötigt werden). Jetzt benutzt jeder Lodash:



Callback Hell. Ich denke, jeder hat den Javascript-Code vor ungefähr 5 Jahren gesehen, und er sah aus wie „Nudeln“ aus den unglaublichen Feinheiten von Rückrufen. Jetzt ist dieses Problem gelöst (mit der Veröffentlichung von ES-15 oder ES-16), sie haben Javascript Versprechungen hinzugefügt und alle begannen für eine Weile leichter zu atmen.



Bis Promice Hell kam ... Ich weiß nicht, wie die Front-End-Branche es schafft, aber sie treiben sich ständig in eine seltsame Wildnis. Sie haben es auch geschafft, die „Versprechen“ zu erfüllen. Dann lösten sie dieses Problem, indem sie ein neues Grundelement hinzufügten - async / await:



Das Problem wird mit Asynchronität gelöst. Async / await ist ein ziemlich beliebtes Grundelement in verschiedenen Sprachen. In "Python" und in anderen gibt es einen solchen Ansatz - er ist gut genug. Das Problem ist gelöst.

Welches Problem ist nicht gelöst? Die Komplexität von Frameworks, die exponentiell wächst, die Komplexität des Ökosystems und der Programme selbst.



  • Die Javasript-Syntax ist etwas seltsam. Wir alle kennen die Probleme beim Hinzufügen eines Arrays, eines Objekts und anderer Witze.
  • Javascript ist ein Multi-Paradigma. Jetzt ist es ein besonders dringendes System, wenn das Ökosystem sehr groß ist:

    • Jeder schreibt in verschiedenen Stilen - jemand schreibt strukturell, jemand schreibt funktional, verschiedene Entwickler schreiben anders;
    • aus verschiedenen Paketen, verschiedenen Paradigmen, wenn Sie verschiedene Pakete verwenden;
    • Die funktionale Programmierung in Javasript macht viel „Spaß“ - die Rambda-Bibliothek ist erschienen und jetzt kann niemand mehr Programme lesen, die in dieser Bibliothek geschrieben sind.

  • Dies alles hat große Auswirkungen auf das Ökosystem und ist unglaublich gewachsen. Pakete sind nicht miteinander kompatibel: jemand mit Versprechungen, jemand mit Async / Warten, jemand mit Rückrufen. Sie schreiben auch in verschiedenen Paradigmen!
  • Dies macht es schwierig, das Projekt aufrechtzuerhalten. Es ist schwer, einen Fehler zu finden, wenn Sie den Code nicht lesen können.

Was ist Web Assemly?


Die tapferen Leute von der Mozilla Foundation und mehreren anderen Unternehmen haben sich so etwas wie Web Assembly ausgedacht. Was ist das?



  • Dies ist eine in den Browser integrierte virtuelle Maschine, die das Binärformat unterstützt.
  • Binäre Programme gelangen dorthin, sie werden fast nativ ausgeführt, dh der Browser muss nicht jedes Mal alle "Nudeln" des Javascript-Codes analysieren.
  • Alle Browser haben Unterstützung deklariert.
  • Da dies ein Bytecode ist, können Sie einen Compiler für jede Sprache schreiben.
  • Vier große Browser bieten bereits Unterstützung für Web Assembly.
  • Bald warten wir auf native Unterstützung in Go. Eine solche neue Architektur wurde bereits hinzugefügt: GOARCH = wasm GOOS = js (bald). Soweit ich es verstehe, ist es nicht funktionsfähig, aber es gibt eine Aussage, dass es definitiv in Go sein wird.

Was nun? Gopherjs


Wir haben zwar keine Web Assembly-Unterstützung, aber es gibt einen Transporter wie GopherJS.



  • Gehen Sie Code-Transpile zu reinem Javascript.
  • – , ( Vanilla JS, ).
  • , Go, … – , .
  • , , : syscall, net- ( net/http-, , XMLHttpRequest). – , stdlib Go, .
  • Go, ( .) GopherJS .

GopherJS zu bekommen ist sehr einfach - dies ist ein reguläres Go-Paket. Wir machen go get und wir haben das GopherJS-Team, um die Anwendung zu erstellen:



Hier ist eine so 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 das Konsolenprotokoll konvertiert und der Browser schreibt "Hello gophers"! So einfach ist das: Wir bauen GopherJS - führen es in einem Browser aus - alles funktioniert!

Was gibt es im Moment? Bindungen




Es gibt Ordner für alle gängigen JS-Frameworks:

  • JQuery
  • Angular.js;
  • D3.js zum Zeichnen und Arbeiten mit Big Data;
  • React.js;
  • VueJS;
  • Es gibt sogar Electron-Unterstützung (das heißt, wir können jetzt Desktop-Anwendungen auf Electron schreiben).
  • und das lustigste ist WebGL (wir können vollgrafische Anwendungen erstellen, einschließlich Spiele mit 3D-Grafik, Musik und allen Extras);
  • und viele andere Ordner für alle gängigen Javascript-Frameworks und -Bibliotheken.

Rahmen


  1. Es gibt bereits ein speziell für GopherJS - Vecty entwickeltes Webframework. Dies ist ein vollwertiges Analogon von React.js, das jedoch nur auf Go mit den Besonderheiten von GopherJS entwickelt wurde.
  2. Es gibt Spieletaschen (plötzlich!). Ich fand zwei der beliebtesten:

    • Engo;
    • Ebiten.

Ich werde ein paar Beispiele zeigen, wie dies aussieht und was Sie jetzt auf Go schreiben können:



Oder eine solche Option (ich habe keinen 3D-Shooter gefunden, aber vielleicht ist es das):



Was schlage ich vor?


Jetzt ist die Front-End-Branche in einem solchen Zustand, dass alle Sprachen, die zuvor aus Javascript geweint haben, dorthin eilen werden. Jetzt werden alle zu Web Assemblies kompiliert. Was brauchen wir, um dort als „Gophers“ einen würdigen Platz einzunehmen?



Go ist traditionell davon ausgegangen, dass es sich um eine Systemprogrammiersprache handelt, und es gibt praktisch keine Bibliotheken für die Arbeit mit der Benutzeroberfläche. Etwas ist da, aber es ist halb verlassen, halb nicht funktionsfähig.

Und hier ist eine gute Chance, UI-Bibliotheken auf Go zu erstellen, die auf GopherJS laufen! Sie können endlich Ihr eigenes Framework schreiben! Es ist an der Zeit, dass Sie ein Framework schreiben können, und er wird einer der ersten sein, der eine frühzeitige Anpassung erhält, und Sie werden ein Star sein (wenn es ein gutes Framework ist).

Sie können viele verschiedene Pakete, die sich bereits im Go-Ökosystem befinden, an die Besonderheiten des Browsers anpassen (z. B. Template Engine). Sie funktionieren bereits. Sie können bequeme Bindungen erstellen, damit Sie Inhalte problemlos direkt im Browser rendern können. Außerdem können Sie beispielsweise einen Dienst erstellen, der auf demselben Server und im Frontend dasselbe mit demselben Code rendern kann - alles ist das, was Front-End-Entwickler mögen (nur jetzt auf Go).

Du kannst ein Spiel schreiben! Nur zum Spaß ...

ich habe es.



Fragen


Frage (im Folgenden - Q): - Schreibe ich in Go oder in Js?

AG: - Sie schreiben Routinen, Kanäle, Strukturen, binden in Go ein - das war's ... Sie abonnieren ein Ereignis, übergeben dort eine Funktion.

F: - Das heißt, ich schreibe auf die "nackten" Js?

AG: - Nein, Sie schreiben wie unterwegs und stellen eine Verbindung zur Browser-API her (die API hat sich nicht gleichzeitig geändert). Sie können Ihre Bindungen so schreiben, dass Nachrichten auf den Kanal gelangen - ganz einfach.

F: - Was ist mit dem Handy?

AG: - Ich habe definitiv gesehen: Es gibt Ordner für den Cordova-Patch, den Js startet. In React Native weiß ich es nicht. vielleicht gibt es, vielleicht nicht (nicht wirklich interessiert). Die N-go-Game-Engine unterstützt auch mobile Anwendungen - sowohl iOs als auch Android.

BEIM:- Frage zur Web Assembly. Trotz der Enge und des "Reißverschlusses" sind immer mehr Plätze besetzt ... Könnten wir die Front-End-Welt auf diese Weise noch mehr töten?

AG: - Web Assembly ist ein Binärformat, und die Binärdatei kann standardmäßig nicht mehr als der Text in der endgültigen Version enthalten sein. Die Laufzeit zieht Sie an, aber sie ist dieselbe wie die Standard-Javascript-Bibliothek, wenn sie nicht vorhanden ist. Daher verwenden wir einige eines Tages lodash. Ich weiß nicht, wie viel Lodash braucht.

F: - Ausdrücklich weniger als die Laufzeit ...

AG: - Auf dem "reinen" Javascript?

F: - Ja. Wir drücken es zusammen, bevor wir es senden ...

AG:- Aber das ist der Text ... Im Allgemeinen sind Megabyte viel, aber das ist alles (Sie haben die gesamte Laufzeit). Als nächstes schreiben Sie Ihre Geschäftslogik, wodurch Ihre Binärdatei um 1% erhöht wird. Bis ich sehe, dass dies das Frontend tötet. Darüber hinaus wird Web Assembly aus dem offensichtlichen Grund schneller als Javascript ausgeführt - es muss nicht analysiert werden.

F: - Bisher ein kontroverser Moment ... Es gibt noch keine Referenzimplementierung von "Vasma" (Web Assembly), so dass Sie klar beurteilen können. Konzeptionell - ja: Wir alle verstehen, dass Binärdateien schneller sein sollten, aber die aktuelle Implementierung derselben V8 ist sehr effektiv.

AG: - Ja.

F: - Die Kompilierung funktioniert dort wirklich cool und es ist keine Tatsache, dass es einen großen Vorteil gibt.

AG: - Web Assembly macht auch tolle Jungs.

BEIM:- Bisher scheint es mir immer noch schwierig zu sein, Web Assembly zu beurteilen. Es wird seit vielen Jahren geredet, und es sind nur wenige echte Erfolge zu spüren.

AG: - Vielleicht. Wir werden sehen.

F: - Wir haben keine Probleme im Backend ... Vielleicht lassen Sie diese Probleme im Frontend? Warum dort klettern?

AG: - Wir müssen das Personal der Frontlinien behalten.


Ein bisschen Werbung :)


Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?

More articles:


All Articles