Get best of the week

Alexey Grachev: Go Frontend

Meetup Kyiv Go mai 2018:



Hôte: - Bonjour à tous! Merci d'être venu ici! Aujourd'hui, nous avons deux conférenciers officiels - Lesha et Vanya. Il y en aura deux de plus si nous avons assez de temps. Le premier orateur est Alexey Grachev, il nous parlera de GopherJS.

Alexey Grachev (ci-après - AG): - Je suis développeur Go et j'écris des services web sur Go. Parfois, vous devez gérer le front-end, parfois vous devez y grimper avec des stylos. Je veux parler de mon expérience et de mes recherches.

La légende est la suivante: d'abord, nous parlerons des raisons pour lesquelles nous voulons exécuter Go sur le front-end, puis nous expliquerons comment cela peut être fait. Il existe deux façons: Web Assembly et GopherJS. Voyons dans quel état sont ces décisions et ce qui peut être fait.

Quel est le problème avec le frontend?


Tout le monde convient-il que tout va bien avec le frontend?



Y a-t-il peu de tests? Montage lent? Écosystème? Bien.

Concernant le frontend, j'aime la citation que l'un des développeurs du frontend a dit dans son livre:



Il n'y a pas de système de type en Javascript. Je vais maintenant nommer les problèmes que j'ai rencontrés au cours de mon travail et expliquer comment ils sont résolus.

Il est généralement difficile d'appeler un système de types un système de types dans Javasript - il y a des lignes qui indiquent le type d'un objet, mais en réalité cela n'a rien à voir avec les types. Ce problème est résolu dans TypeScript (un module complémentaire pour Javasript) et Flow (types de vérificateur statique en Javascript). En fait, l'interface a déjà trouvé la solution au problème d'un système de mauvais type en Javascript.



Il n'y a pas de bibliothèque standard dans le navigateur en tant que telle - il y a des objets intégrés et des fonctions «magiques» dans les navigateurs. Mais je n'ai pas de bibliothèque standard en Javascript en tant que telle. Ce problème a été résolu par jQuery (tout le monde a utilisé jQuery avec tous les prototypes, assistants, fonctions nécessaires au fonctionnement). Maintenant, tout le monde utilise Lodash:



Callback hell. Je pense que tout le monde a vu le code Javascript il y a environ 5 ans, et il ressemblait à des «nouilles» des incroyables subtilités des rappels. Maintenant que ce problème est résolu (avec la sortie de ES-15 ou ES-16), ils ont ajouté des promesses à Javascript et tout le monde a commencé à respirer plus facilement pendant un certain temps.



Jusqu'à ce que Promice hell vienne ... Je ne sais pas comment l'industrie du front-end gère, mais ils se plongent constamment dans d'étranges déserts. Ils ont également réussi à faire l'enfer sur les «promesses». Ensuite, ils ont résolu ce problème en ajoutant une nouvelle primitive - async / wait:



le problème est résolu avec l'asynchronie. Async / Wait est une primitive assez populaire dans différentes langues. Dans "Python" et dans d'autres, il existe une telle approche - elle est assez bonne. Le problème est résolu.

Quel problème n'est pas résolu? La complexité des cadres qui croît de façon exponentielle, la complexité de l'écosystème et des programmes eux-mêmes.



  • La syntaxe Javasript est un peu bizarre. Nous connaissons tous les problèmes avec l'ajout d'un tableau et d'un objet et d'autres blagues.
  • Javascript est multi-paradigme. Maintenant, c'est un système particulièrement urgent lorsque l'écosystème est très vaste:

    • tout le monde écrit dans des styles différents - quelqu'un écrit structurellement, quelqu'un écrit fonctionnellement, différents développeurs écrivent différemment;
    • à partir de différents packages, différents paradigmes lorsque vous utilisez différents packages;
    • il y a beaucoup de "fun" avec la programmation fonctionnelle dans Javasript - la bibliothèque rambda est apparue et maintenant personne ne peut lire les programmes écrits dans cette bibliothèque.

  • Tout cela a un grand impact sur l'écosystème, et il s'est incroyablement développé. Les packages sont incompatibles les uns avec les autres: quelqu'un sur les promesses, quelqu'un sur async / wait, quelqu'un sur les rappels. Ils écrivent également dans différents paradigmes!
  • Cela rend le projet difficile à maintenir. Il est difficile de trouver un bogue si vous ne pouvez pas lire le code.

Qu'est-ce que Web Assemly?


Les braves gars de la Fondation Mozilla et de plusieurs autres sociétés ont proposé une telle chose que Web Assembly. Qu'Est-ce que c'est?



  • Il s'agit d'une machine virtuelle intégrée au navigateur qui prend en charge le format binaire.
  • Les programmes binaires y arrivent, ils sont exécutés presque nativement, c'est-à-dire que le navigateur n'a pas besoin d'analyser tous les "nouilles" de code javascript à chaque fois.
  • Tous les navigateurs ont déclaré leur support.
  • Comme il s'agit d'un bytecode, vous pouvez écrire un compilateur pour n'importe quelle langue.
  • Quatre principaux navigateurs sont déjà fournis avec le support Web Assembly.
  • Bientôt, nous attendons le support natif de Go. Une telle nouvelle architecture a déjà été ajoutée: GOARCH = wasm GOOS = js (bientôt). Jusqu'à présent, si je comprends bien, ce n'est pas fonctionnel, mais il y a une déclaration selon laquelle il sera certainement dans Go.

Que faire maintenant? Gopherjs


Bien que nous n'ayons pas de support Web Assembly, il existe un transporteur tel que GopherJS.



  • Passez du code au Javascript pur.
  • – , ( Vanilla JS, ).
  • , Go, … – , .
  • , , : syscall, net- ( net/http-, , XMLHttpRequest). – , stdlib Go, .
  • Go, ( .) GopherJS .

GopherJS est très facile à obtenir - il s'agit d'un package Go standard. Nous faisons aller chercher, et nous avons l'équipe GopherJS pour construire l'application:



Voici un si petit monde bonjour ...



... Un programme Go régulier, un package fmt régulier de la bibliothèque standard et des Binding Js pour atteindre l'API du navigateur. Println sera finalement converti en journal de la console et le navigateur écrira "Bonjour les gophers"! C'est aussi simple que cela: nous construisons GopherJS - l'exécutons dans un navigateur - tout fonctionne!

Qu'y a-t-il en ce moment? Liaisons




Il existe des liants pour tous les frameworks js populaires:

  • JQuery
  • Angular.js;
  • D3.js pour représenter graphiquement et travailler avec des mégadonnées;
  • React.js;
  • VueJS;
  • il existe même un support Electron (c'est-à-dire que nous pouvons maintenant écrire des applications de bureau sur Electron);
  • et le plus drôle est WebGL (nous pouvons créer des applications graphiques complètes, y compris des jeux avec des graphismes 3D, de la musique et tous les goodies);
  • et de nombreux autres classeurs vers tous les frameworks et bibliothèques javascript populaires.

Cadre


  1. Il existe déjà un framework web spécialement développé pour GopherJS - Vecty. Il s'agit d'un analogue à part entière de React.js, mais uniquement développé sur Go, avec les spécificités de GopherJS.
  2. Il y a des sacs de jeu (tout d'un coup!). J'ai trouvé deux des plus populaires:

    • Engo;
    • Ebiten.

Je vais vous montrer quelques exemples à quoi cela ressemble et ce que vous pouvez écrire sur Go now:



Ou une telle option (je n'ai pas trouvé de jeu de tir 3D, mais peut-être que c'est le cas):



Qu'est-ce que je suggère?


Maintenant, l'industrie front-end est dans un état tel que toutes les langues qui ont pleuré depuis Javascript s'y précipiteront. Maintenant, tout le monde sera compilé dans des assemblys Web. De quoi avons-nous besoin pour y prendre une place digne en tant que «gaufres»?



Go a traditionnellement disparu qu'il s'agit d'un langage de programmation système, et il n'y a pratiquement pas de bibliothèques pour travailler avec l'interface utilisateur. Quelque chose est là, mais il est à moitié abandonné, à moitié non fonctionnel.

Et voici une bonne occasion de créer des bibliothèques d'interface utilisateur sur Go qui fonctionneront sur GopherJS! Vous pouvez enfin écrire votre propre framework! Le temps est venu où vous pouvez écrire un cadre, et il sera l'un des premiers à recevoir une adaptation précoce, et vous serez une star (si c'est un bon cadre).

Vous pouvez adapter un grand nombre de packages différents qui sont déjà dans l'écosystème Go aux spécificités du navigateur (par exemple, le moteur de modèle). Ils fonctionnent déjà, vous pouvez créer des liaisons pratiques pour rendre facilement le contenu directement dans le navigateur. De plus, vous pouvez créer, par exemple, un service qui peut rendre la même chose sur le serveur et sur le frontend en utilisant le même code - tout est ce que les développeurs frontaux aiment (seulement maintenant sur Go).

Vous pouvez écrire un jeu! Juste pour le plaisir ...

je l'ai.



Des questions


Question (ci-après - Q): - Dois-je écrire en Go ou en Js?

AG: - Vous écrivez des routines, des canaux, des structures, l'incorporation sur Go - c'est tout ... Vous vous abonnez à un événement, passez une fonction là-bas.

Q: - Autrement dit, j'écris sur les Js «nus»?

AG: - Non, vous écrivez comme si vous alliez et vous connectez à l'API du navigateur (l'API n'a pas changé en même temps). Vous pouvez écrire vos liaisons pour que les messages arrivent sur la chaîne - c'est facile.

Q: - Et le mobile?

AG: - J'ai bien vu: il y a des reliures pour le patch Cordova que Js lance. Dans React Native, je ne sais pas; peut-être qu'il y en a, peut-être pas (pas vraiment intéressé). Le moteur de jeu N-go prend également en charge les applications mobiles - iOs et Android.

À:- Question sur Web Assembly. De plus en plus de places sont occupées, malgré l'étroitesse, la «fermeture éclair» ... Pourrions-nous tuer encore plus le monde frontal?

AG: - Web Assembly est un format binaire, et le binaire par défaut ne peut pas être dans la version finale plus que le texte ... le runtime vous tire, mais c'est la même chose que la bibliothèque Javascript standard, quand elle n'est pas là, nous utilisons donc certains un jour lodash. Je ne sais pas combien de Lodash prend.

Q: - Explicitement moins que le runtime ...

AG: - Sur le Javascript "pur"?

Q: - Oui. Nous le pressons avant de l'envoyer ...

AG:- Mais c'est le texte ... En général, les mégaoctets, c'est beaucoup, mais c'est tout (vous avez tout le temps d'exécution). Ensuite, vous écrivez votre logique métier, ce qui augmentera votre binaire de 1%. Jusqu'à ce que je vois cela tuer le frontend. De plus, Web Assembly fonctionnera plus rapidement que Javascript pour la raison évidente - il n'a pas besoin d'être analysé.

Q: - Jusqu'à présent, un moment controversé ... Il n'y a toujours pas d'implémentation de référence de "Vasma" (Web Assembly), pour que vous puissiez en juger clairement. Conceptuellement - oui: nous comprenons tous que le binaire devrait être plus rapide, mais l'implémentation actuelle du même V8 est très efficace.

AG: - Oui.

Q: - La compilation fonctionne vraiment bien là-bas et ce n'est pas un fait qu'il y aura un gros avantage.

AG: - Web Assembly fait aussi des gars formidables.

À:- Jusqu'à présent, il me semble, il est encore difficile de juger Web Assembly. Les discussions se poursuivent depuis de nombreuses années et peu de réalisations réelles peuvent être ressenties.

AG: - Peut-être. Nous verrons.

Q: - Nous n'avons aucun problème sur le backend ... Peut-être laisser ces problèmes dans le frontend? Pourquoi y monter?

AG: - Nous devons garder le personnel de première ligne.


Un peu de publicité :)


Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

More articles:


All Articles