Kyiv Go Meetup Mai 2018 :
Animateur : – Bonjour à tous ! Merci d'être ici ! Aujourd'hui, nous avons deux intervenants officiels – Alexe et Vanya. Il y en aura deux autres si nous avons le temps. Le premier intervenant est Alexe Gratchev, qui va nous parler de GopherJS.
Alexe Gratchev (ci-après – AG) : – Je suis développeur Go et j'écris des services web en Go. Parfois, je dois m'attaquer au front-end, parfois je dois y mettre les mains. Je veux partager mon expérience et mes recherches sur Go dans le front-end.
La légende est la suivante : d'abord, nous allons parler de pourquoi nous voulons exécuter Go dans le front-end, puis nous aborderons comment cela peut être fait. Il y a deux voies – Web Assembly et GopherJS. Voyons où en sont ces solutions et ce qui peut être fait.
Qu'est-ce qui ne va pas avec le front-end ?
Tout le monde est d'accord, tout va bien avec le front-end ?
Pas assez de tests ? Compilation lente ? Écosystème ? Très bien.
En ce qui concerne le front-end, j'aime une citation d'un des développeurs front-end dans son livre :
Il n'y a pas de système de types en Javascript. Je vais maintenant énoncer les problèmes que j'ai rencontrés au cours de mon travail et expliquer comment ils sont résolus.
On ne peut pas vraiment appeler le système de types un système de types en Javascript – il y a des chaînes qui désignent le type d'objet, mais en réalité, cela n'a rien à voir avec les types. Ce problème est résolu par TypeScript (une surcouche de Javascript) et Flow (vérificateur de types statiques pour Javascript). En fait, le front-end a déjà abouti à une solution au problème du mauvais système de types en Javascript.
Il n'existe pas de bibliothèque standard dans le navigateur – il y a quelques objets intégrés et des fonctions "magiques" dans les navigateurs. Mais en ce qui concerne Javascript, la bibliothèque standard n'existe pas. Ce problème a déjà été résolu par jQuery (tout le monde utilisait jQuery avec tous les prototypes, helpers, fonctions nécessaires au fonctionnement). Maintenant, tout le monde utilise Lodash :
L'enfer des callbacks. Je pense que tout le monde a vu du code Javascript il y a environ 5 ans, et c'était comme des "nouilles" avec un enchevêtrement incroyable de callbacks. Maintenant, ce problème a été résolu (avec la sortie d'ES-15 ou ES-16), des promesses (promises) ont été ajoutées à Javascript et tout le monde a pu respirer un peu plus facilement pendant un moment.
Jusqu'à ce que vienne l'enfer des promesses... Je ne sais pas comment l'industrie du front-end s'y prend, mais elle continue de s'enfermer dans des recoins étranges. Ils ont réussi à créer un hell avec des "promesses". Ensuite, ils ont résolu ce problème en ajoutant un nouveau primitif – async/await :
Le problème avec l'asynchronicité est résolu. Async/await est un primitif assez populaire dans différents langages. En Python et dans d'autres, il existe une telle approche – elle est très bonne. Le problème est résolu.
Quel problème n'est pas résolu ? La complexité croissante des frameworks en progression géométrique, la complexité de l'écosystème et des programmes eux-mêmes.
- La syntaxe de Javascript est quelque peu étrange. Nous connaissons tous les problèmes de la addition entre tableaux et objets et d'autres particularités.
- Javascript est multi-paradigme. Actuellement, c'est un système particulièrement pertinent, car l'écosystème est très vaste :
- tout le monde écrit dans différents styles – certains écrivent de manière structurée, d'autres de manière fonctionnelle, différents développeurs écrivent différemment ;
- des paradigmes différents provenant de différents packages, lorsque vous utilisez différents paquets ;
- il y a beaucoup de 'divertissement' avec la programmation fonctionnelle en Javascript – la bibliothèque rambda est apparue et maintenant, personne ne peut lire les programmes écrits avec cette bibliothèque.
- Tout cela a un grand impact sur l'écosystème, qui s'est incroyablement développé. Les paquets ne sont pas compatibles entre eux : certains utilisent des promesses, d'autres async/await, d'autres encore des callbacks. En plus, ils sont écrits dans différents paradigmes !
- Cela mène à une difficulté de maintenance des projets. Il est difficile de trouver un bug si vous ne pouvez pas lire le code.
Qu'est-ce que le Web Assembly ?
Les braves gars de la Mozilla Foundation et d'autres entreprises ont inventé ce qu'on appelle le Web Assembly. Qu'est-ce que c'est ?
- C'est une machine virtuelle intégrée dans le navigateur, qui supporte un format binaire.
- Les programmes binaires y arrivent, s'exécutent presque nativement, c'est-à-dire que le navigateur n'a pas besoin de parser tout le 'méli-mélo' du code javascript à chaque fois.
- Tous les navigateurs ont déclaré leur support.
- Puisque c'est du bytecode, on peut écrire un compilateur pour n'importe quel langage.
- Les quatre principaux navigateurs sont déjà livrés avec un support pour le Web Assembly.
- Nous attendons bientôt un support natif dans Go. Une nouvelle architecture a déjà été ajoutée : GOARCH=wasm GOOS=js (bientôt). Pour l’instant, autant que je comprends, cela n'est pas fonctionnel, mais il y a une déclaration indiquant que cela sera certainement ajouté dans Go.
Que faire maintenant ? GopherJS
Tant que nous n'avons pas le support du Web Assembly, il existe un transpileur nommé GopherJS.
- Le code Go est transpile dans du javascript 'pur'.
- Cela fonctionne dans tous les navigateurs – il n'y a pas de nouvelles fonctionnalités qui ne sont prises en charge que par les navigateurs modernes (c'est du Vanilla JS, qui fonctionne sur tout ce qui existe).
- Il existe un support pour presque tout ce qui se trouve dans Go, y compris les goroutines et les canaux… – tout ce que nous aimons et connaissons.
- Presque toute la bibliothèque standard est supportée, à l'exception des paquets qui n'ont pas de sens à supporter dans le navigateur : syscall, interactions réseau (il y a un client net/http, mais pas de serveur, et le client est émulé via XMLHttpRequest). En général, toute la bibliothèque standard est accessible – la voici dans le navigateur, voici la stdlib Go que nous aimons.
- Tout l'écosystème des paquets en Go, toutes les solutions tierces (template et autres) peuvent être compilés avec GopherJS et exécutés dans le navigateur.
Obtenir GopherJS est très facile – c'est un paquet Go ordinaire. Nous faisons go get, et nous avons la commande GopherJS pour construire l'application :
Voici un petit hello world…
…Un programme Go ordinaire, un paquet fmt de la bibliothèque standard et Binding Js, pour accéder à l'API du navigateur. Println sera finalement transformé en console log et le navigateur affichera « Hello gophers » ! C'est aussi simple que ça : nous faisons GopherJS build – exécutons dans le navigateur – tout fonctionne !
Qu'est-ce qui existe actuellement ? Bindings
Il existe des bindings pour tous les frameworks js populaires :
- JQuery;
- Angular.js;
- D3.js pour créer des graphiques et travailler avec de grandes données;
- React.js;
- VueJS;
- il y a même un support pour Electron (c'est-à-dire que nous pouvons déjà écrire des applications de bureau sur « Electron »);
- et le plus amusant – c'est WebGL (nous pouvons créer des applications holographiques, y compris des jeux avec des graphismes 3D, de la musique et tous les extras);
- et beaucoup d'autres bindings pour tous les frameworks et bibliothèques javascript populaires.
Framework
- Il existe déjà un framework web spécialement conçu pour GopherJS – Vecty. C'est un véritable équivalent de React.js, mais développé en Go, avec les spécificités de GopherJS.
- Il y a des moteurs de jeu (surprise !). J'ai trouvé les deux plus populaires :
- Engo;
- Ebiten.
Je vais montrer quelques exemples, à quoi cela ressemble et ce que nous pouvons déjà écrire en Go :
Ou une telle option (je n'ai pas trouvé de FPS 3D, mais peut-être qu'il y en a) :
Que proposez-vous ?
Actuellement, l'industrie du frontend est dans un tel état, que tous les langages qui auparavant pleuraient à cause de Javascript se jetteront maintenant là-dedans. Maintenant, tous seront compilés en « Web Assembly ». Que devons-nous faire pour occuper une place respectable là-bas en tant que « gophers » ?
Dans Go, c'est traditionnellement considéré comme un langage de programmation système, et il n'y a pratiquement pas de bibliothèques pour travailler avec l'interface utilisateur. Il y a quelques choses, mais c'est à moitié abandonné, à moitié non fonctionnel.
Et voici une bonne occasion de créer des bibliothèques UI en Go qui fonctionneront sur GopherJS ! On peut enfin écrire notre propre framework ! C'est le moment de créer un framework, et il sera l'un des premiers et adoptera tôt, et vous serez une star (si c'est un bon framework).
On peut adapter une multitude de paquets qui existent déjà dans l'écosystème Go aux spécificités du navigateur (par exemple, un moteur de templates). Ils fonctionneront déjà, et on peut créer des enveloppes pratiques pour rendre facilement du contenu directement dans le navigateur. De plus, on peut créer un service qui sait rendre la même chose sur le serveur et sur le frontend, en utilisant le même code – tout ce que les développeurs frontend apprécient (mais désormais en Go).
On peut écrire un jeu ! Juste pour le plaisir…
C'est tout pour moi.
Questions
Question (ci-après – Q) : – Est-ce que j'écris en Go ou en Js ?
AG : – Tu écris en Go pour les routines, les canaux, les structures, l'embedding – tout ça… Tu t'inscris à un événement, tu y passes une fonction.
Q : – Donc j'écris en "Javascript pur" ?
AG : – Non, tu écris plutôt en Go et tu te connectes à l'API du navigateur (l'API n'a pas changé). Tu peux écrire tes propres enveloppes pour que des messages arrivent dans le canal – ce n'est pas compliqué.
Q : – Qu'en est-il du mobile ?
AG : – J'ai clairement vu : il existe des bindings pour le patch Cordova, qui lancent Js. Quant à React Native – je ne sais pas ; il y en a peut-être, ou pas (je ne me suis pas trop intéressé). Le moteur de jeu N-go prend en charge les applications mobiles – à la fois iOS et Android.
Q : – Questions sur le Web Assembly. Cela occupe de plus en plus de place, malgré la compression, la "zippéité"… Ne détruirons-nous pas ainsi le monde du frontend encore plus ?
AG : – Web Assembly est un format binaire, et par défaut, un binaire ne peut pas être plus gros que du texte dans la version finale… Tu es tenté par le runtime, mais c'est comme tirer une bibliothèque Javascript standard lorsque tu ne l'as pas, donc nous utilisons une sorte de Lodash. Je ne sais pas combien Lodash prend.
Q : – Clairement moins que le runtime…
AG : – En "Javascript pur" ?
Q : – Oui. Nous le compressons avant de l'envoyer…
AG : – Mais c'est un texte... En gros, un mégaoctet, c'est beaucoup, mais c'est tout (tu as tout ton runtime). Ensuite, tu écris ta logique métier, qui augmentera de 1 % ton binaire. Pour l'instant, je ne vois pas que cela affecte le frontend. D'autant plus que Web Assembly fonctionnera plus rapidement que Javascript pour une raison évidente : il n'a pas besoin d'être analysé.
Q : – C'est encore un point discutable... Il n'y a pas encore de réalisation étalon de « Vasma » (Web Assembly), donc on ne peut pas juger de manière définitive. Conceptuellement, oui : nous comprenons tous que le binaire doit être plus rapide, mais la mise en œuvre actuelle de V8 est très efficace.
AG : – Oui.
Q : – La compilation fonctionne vraiment très bien là-bas et il n'est pas certain qu'il y aura un grand avantage.
AG : – Web Assembly est également développé par de grands acteurs.
Q : – Pour l'instant, il me semble encore difficile de porter un jugement sur Web Assembly. Cela fait des années que nous en discutons, mais les réalisations concrètes que l'on peut toucher sont rares.
AG : – Peut-être. Nous verrons bien.
Q : – Nous n'avons pas de problèmes côté backend... Peut-être devrions-nous laisser ces problèmes au frontend ? Pourquoi s'y mêler ?
AG : – Nous devons maintenir une équipe de frontenders.
Un peu de publicité 🙂
Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, , un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).
Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur
Source : habr.com
