Kyiv Go Meetup mai 2018 :
Modérateur - Salut tout le monde! Merci d'être ici! Aujourd'hui, nous avons deux intervenants officiels - Lyosha et Vanya. Il y en aura deux autres si nous avons suffisamment de temps. Le premier intervenant est Alexey Grachev, il nous parlera de GopherJS.
Alexey Grachev (ci-après – AG) : – Je suis un développeur Go et j’écris des services Web en Go. Parfois, vous devez gérer le frontend, parfois vous devez y accéder manuellement. Je veux parler de mon expérience et de mes recherches sur Go sur le frontend.
La légende est la suivante : nous parlerons d’abord de la raison pour laquelle nous voulons exécuter Go sur le frontend, puis nous parlerons de la manière dont cela peut être fait. Il existe deux manières : Web Assembly et GopherJS. Voyons quel est le statut de ces solutions et ce qui peut être fait.
Quel est le problème avec l'interface ?
Tout le monde est-il d’accord sur le fait que tout va bien avec le frontend ?
Il n'y a pas assez de tests ? Une construction lente ? Écosystème ? Bien.
Concernant le frontend, j'aime la citation qu'un des développeurs frontend a dit dans son livre :
Javascript n'a pas de système de types. Je vais maintenant nommer les problèmes que j'ai rencontrés au cours de mon travail et expliquer comment ils sont résolus.
Le système de types en général peut difficilement être appelé système de types dans Javasript - il y a des lignes qui indiquent le type de l'objet, mais en fait cela n'a rien à voir avec les types. Ce problème est résolu dans TypeScript (un module complémentaire à Javasript) et Flow (un vérificateur de type statique en Javascript). En fait, le frontend a déjà atteint le point de résoudre le 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 tel - il existe des objets intégrés et des fonctions « magiques » dans les navigateurs. Mais en Javascript, il n’existe pas de bibliothèque standard en tant que telle. Ce problème a déjà été résolu une fois par jQuery (tout le monde utilisait jQuery avec tous les prototypes, assistants, fonctions nécessaires au fonctionnement). Désormais, tout le monde utilise Lodash :
Rappel en enfer. Je pense que tout le monde a vu du code Javascript il y a environ 5 ans, et cela ressemblait à une « nouille » d'une incroyable complexité de rappels. Maintenant, ce problème a été résolu (avec la sortie de l'ES-15 ou de l'ES-16), des promesses ont été ajoutées à Javascript et tout le monde peut mieux respirer pendant un moment.
Jusqu'à ce que l'enfer de Promice arrive... Je ne sais pas comment l'industrie du front-end se débrouille, mais ils s'enfoncent toujours dans une jungle étrange. Nous avons également réussi à faire un enfer sur nos promesses. Ensuite, nous avons résolu ce problème en ajoutant une nouvelle primitive - async/await :
Le problème de l'asynchronie est résolu. Async/await est une primitive assez populaire dans diverses langues. Python et d'autres ont cette approche - c'est plutôt bien. Problème résolu.
Quel problème n'est pas résolu ? La complexité exponentielle des cadres, la complexité de l'écosystème et des programmes eux-mêmes.
- La syntaxe Javascript est un peu étrange. Nous connaissons tous les problèmes liés à l'ajout d'un tableau, d'un objet et d'autres blagues.
- Javascript est multi-paradigme. Il s’agit d’un système particulièrement urgent à l’heure où l’écosystème est très vaste :
- tout le monde écrit dans des styles différents - certains écrivent de manière structurelle, certains écrivent de manière fonctionnelle, 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 « amusant » 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 impact important sur l’écosystème, et celui-ci s’est incroyablement développé. Les packages sont incompatibles entre eux : certains sont basés sur des promesses, certains sont basés sur async/wait, certains sont basés sur des rappels. Ils écrivent aussi dans des paradigmes différents !
- Cela rend le projet difficile à maintenir. Il est difficile de trouver un bug si vous ne pouvez pas lire le code.
Qu’est-ce que l’assemblage Web ?
Les courageux gars de la Fondation Mozilla et d'un certain nombre d'autres sociétés ont imaginé une solution telle 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 et sont exécutés presque nativement, c'est-à-dire que le navigateur n'a pas besoin d'analyser toutes les « nouilles » du code javascript à chaque fois.
- Tous les navigateurs ont déclaré leur support.
- Puisqu'il s'agit de bytecode, vous pouvez écrire un compilateur pour n'importe quel langage.
- Quatre navigateurs majeurs sont déjà livrés avec la prise en charge de Web Assembly.
- Nous attendons bientôt un support natif dans Go. Cette nouvelle architecture a déjà été ajoutée : GOARCH=wasm GOOS=js (bientôt). Pour autant que je comprends, il n'est pas fonctionnel, mais il y a une déclaration selon laquelle ce sera certainement dans Go.
Que faire maintenant? GopherJS
Bien que nous ne prenions pas en charge Web Assembly, il existe un transpilateur comme GopherJS.
- Le code Go est transpilé en Javascript « pur ».
- Fonctionne dans tous les navigateurs - il n'y a pas de nouvelles fonctionnalités prises en charge uniquement par les navigateurs modernes (il s'agit de Vanilla JS, qui fonctionne sur n'importe quoi).
- Il existe un support pour presque tout ce que Go propose, y compris les goroutines et les chaînes... tout ce que nous aimons et connaissons tant.
- Presque toute la bibliothèque standard est prise en charge, à l'exception des packages qu'il n'est pas logique de prendre en charge dans le navigateur : syscall, net interactions (il existe 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 disponible - la voici dans le navigateur, voici stdlib Go, que nous adorons.
- L'ensemble de l'écosystème de packages dans Go, toutes les solutions tierces (modèles, etc.) peuvent être compilés à l'aide de GopherJS et exécutés dans le navigateur.
GopherJS est très facile à obtenir - c'est juste un package Go classique. Nous allons chercher, et nous avons une commande GopherJS pour construire l'application :
C'est un si petit bonjour le monde...
...Un programme Go standard, un package fmt de bibliothèque standard standard et Binding Js pour accéder à l'API du navigateur. Println sera finalement converti en journal de console et le navigateur écrira « Hello Gophers » ! C'est aussi simple que ça : nous construisons GopherJS – nous le lançons dans le navigateur – tout fonctionne !
Qu'est-ce que tu as en ce moment ? Reliures
Il existe des liaisons pour tous les frameworks js populaires :
- JQuery ;
- Angulaire.js ;
- D3.js pour tracer et travailler avec le Big Data ;
- Réagir.js ;
- VueJS ;
- il existe même un support pour Electron (c'est-à-dire que nous pouvons déjà écrire des applications de bureau sur Electron) ;
- et le plus drôle, c'est WebGL (nous pouvons créer des applications entièrement graphiques, y compris des jeux avec des graphismes 3D, de la musique et tous les goodies) ;
- et de nombreuses autres liaisons à tous les frameworks et bibliothèques javascript populaires.
Framework
- Il existe un framework web déjà développé spécifiquement pour GopherJS - Vecty. Il s'agit d'un analogue à part entière de React.js, mais uniquement développé en Go, avec les spécificités de GopherJS.
- Il y a des carniers (surprise !). J'ai trouvé les deux plus populaires :
- Engo;
- Ébiten.
Je vais vous montrer quelques exemples de ce à quoi cela ressemble et de ce que vous pouvez déjà écrire dans Go :
Ou cette option (je n'ai pas trouvé de jeu de tir 3D, mais peut-être qu'il existe) :
Qu'est-ce que je propose ?
Maintenant, l'industrie front-end est dans un tel état que tous les langages qui criaient auparavant à Javascript s'y précipiteront. Maintenant, tout sera compilé dans des « Web Assemblies ». De quoi avons-nous besoin pour y prendre la place qui nous revient en tant que Gophers ?
Go a traditionnellement supposé qu'il s'agissait d'un langage de programmation système et qu'il n'existait pratiquement aucune bibliothèque pour travailler avec l'interface utilisateur. Il y a quelque chose, mais il est à moitié abandonné, à moitié non fonctionnel.
Et c’est maintenant une bonne occasion de créer des bibliothèques d’interface utilisateur dans Go qui fonctionneront sur GopherJS ! Vous pouvez enfin écrire votre propre framework ! C'est le moment où vous pourrez écrire un framework, et il sera l'un des premiers et sera adopté rapidement, et vous serez une star (si c'est un bon framework).
Vous pouvez adapter de nombreux packages différents déjà présents dans l'écosystème Go aux spécificités du navigateur (par exemple, le moteur de modèles). Ils fonctionneront déjà, vous pouvez créer des liaisons pratiques afin de pouvoir facilement restituer le contenu directement dans le navigateur. De plus, vous pouvez créer, par exemple, un service qui peut restituer la même chose sur le serveur et sur le front-end, en utilisant le même code - tout ce que les développeurs front-end aiment (uniquement maintenant dans Go).
Vous pouvez écrire un jeu ! Juste pour le fun...
J'ai tout.
des questions
Question (ci-après dénommée Q) : – Est-ce que j’écris en Go ou en Js ?
AG : – Vous écrivez des routines, des canaux, des structures, des embeddings – tout en Go... Vous vous abonnez à un événement, y passez une fonction.
В: – Alors j’écris en J « nus » ?
AG : – Non, vous écrivez comme dans Go et vous vous connectez à l’API du navigateur (l’API n’a pas changé). Vous pouvez écrire vos propres liaisons pour que les messages soient envoyés au canal - ce n'est pas difficile.
В: – Et le mobile ?
AG : – J'ai bien vu : il existe des liaisons pour le patch Cordova que Js exécute. Dans React Native - je ne sais pas ; peut-être qu’il y en a, peut-être pas (je n’étais pas particulièrement intéressé). Le moteur de jeu N-go prend en charge les deux applications mobiles – iOS et Android.
В: – Question sur l’assemblage Web. De plus en plus de place est prise, malgré la compression et le « zipping »… Ne tuera-t-on pas ainsi encore plus le monde front-end ?
AG : – Web Assembly est un format binaire, et le binaire par défaut ne peut pas être plus présent que le texte dans la version finale... Vous êtes attiré par l'exécution, mais cela revient à faire glisser la bibliothèque Javascript standard lorsqu'elle n'est pas là, nous utilisez du Lodash. Je ne sais pas combien de Lodash prend.
В: – Évidemment moins que le temps d'exécution...
AG : – En Javascript « pur » ?
В: - Oui. Nous le compressons avant de l'envoyer...
AG : – Mais c'est du texte... En général, un mégaoctet semble beaucoup, mais c'est tout (vous avez tout le runtime). Ensuite, vous écrivez votre propre logique métier, ce qui augmentera votre binaire de 1 %. Jusqu'à présent, je ne vois pas cela tuer le frontend. De plus, Web Assembly fonctionnera plus rapidement que Javascript pour une raison évidente : il n'a pas besoin d'être analysé.
В: – C'est encore un point controversé... Il n'existe pas encore d'implémentation de référence de « Vasma » (Web Assembly) pour que l'on puisse juger sans ambiguïté. 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.
В: – La compilation là-bas fonctionne vraiment très bien et ce n’est pas un fait qu’il y aura un gros avantage.
AG : – Le Web Assembly est également réalisé par des grands.
В: – Il me semble qu’il est encore difficile de juger le Web Assembly. Des discussions ont eu lieu depuis de nombreuses années, mais peu de véritables réalisations peuvent être ressenties.
AG : - Peut être. Nous verrons.
В: – Nous n’avons pas de problèmes sur le backend… Peut-être devrions-nous laisser ces problèmes sur le frontend ? Pourquoi y aller ?
AG : – Il faut garder un effectif de travailleurs de première ligne.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com