Discussion :

[Stéphane le calme]

Go et WebAssembly, une alternative prometteuse à React ? Dagger tente l'approche pour optimiser les performances de son frontend
et unifier sa base de code

L’architecture des applications web modernes repose généralement sur des bibliothèques JavaScript populaires comme React, Vue.js ou Angular, qui permettent de gérer l’interactivité et le rendu dynamique du contenu dans les navigateurs. Cependant, ces solutions, bien que robustes, viennent avec leurs propres défis, notamment en termes de performance, de complexité et de gestion des différentes interfaces utilisateurs.

Dans un mouvement qui pourrait redéfinir certaines approches du développement frontend, Dagger, une plateforme d'intégration et de déploiement continu (CI/CD), a décidé de se détacher des frameworks JavaScript traditionnels pour réinventer son interface utilisateur avec une technologie qui ne cesse de croître : Go et WebAssembly (WASM). Ce choix de remplacer React par Go couplé à WebAssembly a suscité un grand intérêt dans le domaine du développement, tant pour ses avantages que pour les défis qu’il soulève.

Dagger Cloud fournit une traçabilité unifiée et de bout en bout pour les builds et les tests - indépendamment des CI, des environnements de développement, des langages et des plates-formes. Tout ce que Dagger Engine peut exécuter, Dagger Cloud peut le tracer.

Quel en est l'intérêt ? Les développeurs expliquent : « "Qu'est-ce qui n'a pas fonctionné ? Pourquoi est-ce si lent ?" Si vous avez déjà perdu du temps à regarder les journaux de CI pour répondre à ces questions, il est temps d'adopter le traçage. Cela vous aidera à optimiser vos constructions et à résoudre plus rapidement les problèmes lorsque les choses tournent mal ».

Le contexte : un besoin de cohérence et de performance

« Il y a quelques semaines, nous avons lancé Dagger Cloud v3, une toute nouvelle interface utilisateur pour Dagger Cloud. L'une des principales différences entre la v3 et son prédécesseur v2 est que la nouvelle interface utilisateur est écrite en WebAssembly (WASM) à l'aide de Go. À première vue, ce choix peut sembler étrange (Go n'est généralement pas le premier langage auquel on pense lorsqu'on décide de programmer une interface utilisateur Web) mais nous avions de bonnes raisons ».

Avant de s'engager dans cette refonte, Dagger faisait face à une situation où deux interfaces utilisateurs distinctes étaient en parallèle :

• L'interface de terminal (TUI) développée en Go, directement intégrée au CLI de Dagger.
• L'interface Cloud développée en React pour le tableau de bord web, utilisé pour l’interaction avec les utilisateurs.

Maintenir deux interfaces différentes engendrait des défis majeurs. D’une part, la duplication du code ralentissait le développement. Chaque nouvelle fonctionnalité devait être réécrite et testée sur deux plateformes distinctes, ce qui non seulement alourdissait le processus de développement, mais aussi augmentait les risques d’incohérences entre les deux interfaces. D’autre part, la gestion des performances de l’interface Cloud devenait de plus en plus complexe. En particulier, la plateforme devait gérer de grandes quantités de données en temps réel, ce qui ralentissait l’expérience utilisateur et rendait l'interface moins réactive, surtout dans des scénarios de forte utilisation.

Deux bases de code = plus de travail, moins de fonctionnalités

Dagger fonctionne en construisant un DAG d'opérations et en les évaluant, souvent en parallèle. Par nature, il s'agit d'une chose difficile à afficher. Pour aider les utilisateurs à s'y retrouver, nous proposons deux interfaces de visualisation en temps réel : l'interface terminale de Dagger (TUI), incluse dans le CLI de Dagger, et Dagger Cloud, un tableau de bord Web en ligne. L'interface utilisateur de Dagger est implémentée en Go, et Dagger Cloud (pré-v3) a été écrit en React.

Il est évident que nous voulons que les deux interfaces utilisateur soient aussi proches que possible l'une de l'autre. Mais l'interprétation du flux d'événements de Dagger en temps réel et la production d'une interface utilisateur sont des tâches assez complexes. Certains des flux d'événements les plus complexes que nous ayons vus contiennent des centaines de milliers de données OpenTelemetry, et la gestion des structures de données qui les entourent devient très compliquée, très rapidement. L'interface Web ne pouvait souvent pas suivre l'énorme volume de données qu'elle devait traiter et elle devenait lente et laggy ; pour résoudre ce goulot d'étranglement des performances, nous avons été contraints d'adopter un modèle d'implémentation différent pour l'application React.

Nous nous sommes donc retrouvés avec deux interfaces essayant d'accomplir la même chose, l'une dans un langage et un écosystème (TypeScript/React), l'autre dans un langage et un écosystème totalement différents (Go), et nous ne pouvions pas facilement partager la logique métier entre elles. En tant que petite équipe, nous devons livrer rapidement. Avoir à réimplémenter chaque fonctionnalité deux fois était une taxe massive sur notre vélocité.

Nous avons commencé à réfléchir à une nouvelle approche de Dagger Cloud, avec deux objectifs principaux :

• Unifier les bases de code, afin d'éliminer les doublons et de rendre plus efficace la livraison de nouvelles fonctionnalités.
• Tenir la promesse d'une interface Web claire et rapide, à la hauteur de la vitesse et de la performance de l'interface du terminal.

C’est dans ce contexte qu’une réflexion profonde a été menée, aboutissant à la décision de remplacer l’interface frontend React par une solution unifiée, basée sur Go et WebAssembly.

Go et WebAssembly : la solution choisie

Le choix de Go et WebAssembly ne s’est pas fait par hasard. Ce combo représente une approche relativement novatrice mais prometteuse pour le développement frontend, et ce pour plusieurs raisons.

Go : La Cohérence et la Productivité

Go, un langage de programmation compilé développé par Google, est particulièrement apprécié pour sa simplicité, sa rapidité et son efficacité. Son adoption au sein de Dagger était déjà bien ancrée pour le développement de leur interface en ligne de commande (CLI) et du backend. L'utilisation de Go pour l'interface utilisateur présente plusieurs avantages :

• Unité de code : En choisissant Go, l’équipe de développement a pu unifier l’écriture du code backend et frontend. Cela facilite non seulement la maintenance, mais aussi la collaboration entre les équipes de développement, qui sont toutes familières avec le même langage.
• Haute performance : Go étant un langage compilé, il offre des performances supérieures à celles des langages interprétés comme JavaScript. Ce facteur est essentiel pour des applications qui manipulent une grande quantité de données, comme c’est le cas de Dagger.
• Simplicité : Go est réputé pour sa syntaxe simple et son faible coût d’apprentissage, ce qui facilite la prise en main pour les développeurs, même ceux venant de langages de programmation plus complexes.

WebAssembly : L’exécution nativement dans le navigateur

WebAssembly (WASM) est une technologie qui permet d'exécuter du code à grande vitesse dans les navigateurs, presque à la vitesse native. L’une des caractéristiques principales de WASM est sa capacité à exécuter des langages autres que JavaScript dans l’environnement du navigateur, avec un rendu extrêmement rapide et efficace.

• Performance accrue : WASM permet à Dagger de déplacer des parties du code à exécuter directement dans le navigateur, au lieu de dépendre uniquement du JavaScript. Cela permet de maximiser les performances, surtout dans des cas d’utilisation avec de lourdes opérations de calcul.
• Portabilité : Le code Go compilé en WebAssembly peut être exécuté dans n’importe quel navigateur moderne, sans nécessiter de plugins supplémentaires. Cette portabilité est un atout majeur, car elle permet à Dagger de s’assurer que son application web fonctionne de manière fluide sur une large gamme de plateformes et de dispositifs.
• Réduction de la charge serveur : En déplaçant certaines tâches côté client grâce à WASM, Dagger a pu alléger la charge des serveurs, réduisant ainsi les coûts d'infrastructure et améliorant la réactivité de l’application.

Avec Dagger Cloud v3, nous voulions offrir une expérience plus fluide et plus rapide tout en maintenant une parité complète avec l'interface utilisateur du terminal Dagger, nous avons donc adopté WebAssembly (WASM).

L'adoption de WebAssembly (WASM) a été l'une des tendances croissantes dans l'écosystème du cloud au cours des dernières années. Et pour cause ! WASM vous permet d'exécuter du code écrit dans différents langages de programmation (comme Go, Rust, C++, etc.) dans des navigateurs web ou d'autres environnements à une vitesse quasi native.

En remplaçant notre ancienne application React par une interface utilisateur basée sur WebAssembly, nous avons unifié la logique commerciale sous-jacente entre le terminal Dagger et les expériences web. Auparavant, le maintien d'implémentations séparées en TypeScript/React (pour le web) et Go (pour le CLI) créait des doublons et ralentissait notre capacité à livrer des fonctionnalités de manière cohérente sur toutes les plateformes. Désormais, avec WASM, l'interface terminal et l'interface web partagent la même base de code backend.

Pour construire notre nouvelle interface utilisateur, nous avons utilisé Go-app, un framework Go pour les applications web progressives, qui a facilité la concrétisation de notre vision basée sur WebAssembly.

Des erreurs plus faciles à lire

Les défis du passage à Go et WebAssembly

Bien que les avantages de cette approche soient évidents, la transition n’a pas été sans difficultés. Le passage de React à Go et WebAssembly a demandé un investissement important en termes de temps, de ressources et de compétences techniques.

• Maturité technologique de WASM : Le manque d'outils et de bibliothèques adaptées a obligé l’équipe de Dagger à développer eux-mêmes de nombreux composants frontend, ce qui a allongé le temps de développement.
• Limites de la mémoire WebAssembly : Le standard WebAssembly impose des limites de mémoire qui, bien qu’ayant été étendues dans les dernières versions des navigateurs, restent relativement faibles (environ 2 Go par application). Ce paramètre est particulièrement contraignant pour des applications qui doivent traiter de grandes quantités de données en temps réel, comme c’est le cas pour Dagger.
• Expérience utilisateur : Le passage de React, un framework optimisé pour le rendu d’interfaces riches et dynamiques, à une solution en Go et WebAssembly, a nécessité de repenser une partie de l’interactivité et de l’ergonomie de l’interface. Les composants web devaient être réinventés, ce qui a demandé une phase de prototypage et de tests exhaustive.

Notre objectif initial était de pouvoir réutiliser une base de code pour Dagger Cloud et l'interface utilisateur. Nous avons décidé assez tôt d'en faire une base de code Go. Techniquement, nous aurions pu faire l'inverse et utiliser TypeScript pour l'interface utilisateur. Mais nous sommes avant tout une équipe d'ingénieurs Go, et le choix de Go a permis aux autres membres de l'équipe de contribuer plus facilement, d'ajouter une fonctionnalité ou de passer quelques heures pour aider à déboguer un problème. En plus de la standardisation sur un seul langage, cela nous a donné de la flexibilité et a brisé les silos au sein de notre équipe.

Une fois que nous avons décidé d'exécuter le code Go directement dans le navigateur, WebAssembly était l'étape suivante logique. Mais il restait encore quelques défis à relever :

• La combinaison Go + WebAssembly n'est pas encore aussi mature que React et d'autres frameworks JavaScript. Il n'existe pas de bibliothèques de composants prêts à l'emploi, les outils de développement ne sont pas aussi riches, etc. Nous savions que nous devrions créer la plupart de nos composants d'interface utilisateur à partir de zéro.
• Les applications WebAssembly sont soumises à une limite de mémoire de 2 Go dans la plupart des navigateurs. Nous nous attendions à ce que cela pose un problème lors de l'affichage de traces volumineuses, et nous savions que nous devrions faire beaucoup d'optimisation pour minimiser l'utilisation de la mémoire et maintenir l'interface utilisateur stable. Mais ce n'était pas entièrement mauvais ; le point positif était que toute amélioration de l'utilisation de la mémoire apportée à l'interface WebAssembly profiterait également aux utilisateurs de l'interface utilisateur, puisqu'il s'agissait maintenant d'une base de code partagée.

Des indicateurs d'état plus clairs

Les résultats : une interface plus performante et cohérente

Malgré ces défis, la refonte a été couronnée de succès. Les résultats ont été significatifs :

• Performance améliorée : La gestion des données en temps réel est devenue beaucoup plus fluide. L’application est désormais plus réactive, avec des temps de réponse plus rapides et une expérience utilisateur nettement améliorée.
• Unité et cohérence : L’unification du code backend et frontend sous Go a facilité la maintenance et la collaboration entre les équipes. En éliminant la duplication du travail, Dagger a gagné en efficacité et a réduit les risques d’incohérences dans le développement.
• Réduction de la taille du fichier WASM : L’optimisation de la taille des fichiers WASM, notamment grâce à la compression Brotli, a permis de réduire de manière significative la taille du code à charger, améliorant ainsi les temps de chargement des pages.

Une fois la décision prise, la question suivante était : « Comment allons-nous construire cela ? » Nous avons décidé de construire la nouvelle interface utilisateur basée sur WebAssembly dans le framework Go-app. Go-app est un framework de haut niveau spécialement conçu pour les Progressive Web Apps (PWA) en WebAssembly. Il offre des avantages clés de Go, comme la compilation rapide et le typage statique natif, et il suit également un modèle d'interface utilisateur basé sur des composants, comme React, ce qui a facilité la transition.

La combinaison Go + WebAssembly n'étant pas très répandue, l'équipe de Dagger a fait preuve d'un certain scepticisme quant à sa faisabilité. Par exemple, il n'y avait pas de véritable écosystème pour les composants d'interface utilisateur Go-app et nous savions que nous devrions écrire les nôtres, mais nous n'étions pas sûrs de la facilité ou de la difficulté de cette tâche. Nous étions également préoccupés par les intégrations avec d'autres services (Tailwind, Auth0, Intercom, PostHog), et par le rendu de plusieurs centaines de composants mis à jour en direct en même temps.

Pour répondre à ces questions et réduire les risques du projet, j'ai passé près d'un mois à prototyper, avec l'objectif de réimplémenter autant que possible l'interface utilisateur existante dans Go-app. Il s'est avéré qu'il n'y avait pas beaucoup d'obstacles : WebAssembly est déjà un standard ouvert bien documenté et la plupart des autres questions ont trouvé leur réponse dans la documentation de Go-app. Le plus grand défi, comme prévu, était la limite d'utilisation de la mémoire, qui a nécessité une conception et une optimisation minutieuses.

L’avenir du développement frontend : Go et WebAssembly comme solutions viables ?

L’expérience de Dagger soulève plusieurs questions intéressantes sur l'avenir du développement frontend. Le modèle Go + WebAssembly semble être une alternative prometteuse aux frameworks JavaScript traditionnels, notamment pour les applications qui nécessitent une gestion intensive des données ou des performances optimisées. Cependant, cette approche reste relativement nouvelle et nécessite une expertise technique poussée.

Il est donc probable que dans les années à venir, des solutions hybrides ou plus complètes émergeront, combinant les meilleures caractéristiques de Go, WebAssembly et des frameworks frontend populaires comme React. La clé résidera dans l’adaptation de ces technologies aux besoins spécifiques de chaque projet, et dans l’émergence de nouvelles bibliothèques et outils pour simplifier leur adoption.

Source : Dagger (1, 2)

Et vous ?

Quel rôle l’utilisation de Go dans le frontend pourrait-elle jouer dans la réévolution du paradigme des frameworks JavaScript ? Est-ce le début d'une tendance plus large ?

Quels sont les avantages et inconvénients de la combinaison Go + WebAssembly par rapport à des technologies comme Rust ou Blazor pour des applications frontend complexes ?

Dans quelle mesure la gestion de la mémoire et des limites de taille des fichiers dans WebAssembly peut-elle affecter les applications à grande échelle, comme les plateformes de streaming ou les applications de données volumineuses ?

Pensez-vous que l’approche Go + WASM soit adaptée à d’autres types de projets (par exemple, des applications à forte interactivité ou à grand volume de contenu multimédia) ?

Est-ce que la forte spécialisation des équipes techniques (Go dans ce cas) pourrait devenir un obstacle pour les entreprises souhaitant adopter cette approche, étant donné la courbe d’apprentissage ?

Envisageriez-vous d’autres solutions pour optimiser la performance des interfaces web modernes tout en gardant la souplesse et l’ergonomie de frameworks comme React ?

Voir aussi :

Exécuter des programmes C dans le navigateur en utilisant le runtime WebAssembly « une étape majeure pour faire fonctionner n'importe quel logiciel avec WebAssembly », d'après Wasmer

Le langage Go souffle ses 15 bougies et atteint sa position la plus haute sur l'indice Tiobe, Google annonce que le nombre d'utilisateurs de Go a plus que triplé au cours des cinq dernières années

L'équipe de Meta annonce la sortie de React 19, qui introduit de nouvelles fonctionnalités et améliorations : fonctions asynchrones, composants/actions serveur et prise en charge d'éléments personnalisés

[Invité]

Etant un peu beaucoup novice en langages web, mon avis sur cette transition est à prendre avec des pincettes... Mais Go + WASM n'est-ce pas une solution plus sécurisée que les frameworks js ? Et ensuite, n'est-ce pas une bonne nouvelle l'optimisation de la mémoire dans WASM quand on voit que le moindre site web prend au moins 100Mo dans un onglet sauf DVP et les vieux sites ?

[nhugodot]

Ils ont choisi Go parce que leur backend et donc équipe faisait du go.
Quid s'ils avaient eu un backend classique en PHP, Python, Ruby, Java, voire maintenant en Élixir, Rust, etc
Est-ce que tout langage back a un intérêt à devenir front pour ce type de raison ? Manque de librairies front et d'outils, mais aussi culture front différente de la culture back chez les ingénieurs , ce n'est pas la même chose...
Cela dit le succès inverse de JS passé du front au back avec Node a montré sa pertinence.
Quel autre langage pourrait donc avoir le même succès en passant du back au front ? PHP et Python voire Java, qui d'ailleurs à ses débuts était ''code once run everywhere '' et donc conçu pour être téléchargeable et sur un front, absolument pas en back! (C'est même une hérésie en réalité...)

Vu l'enseignement généralisé de Python , la vague IA, les LLM entraînés très majoritairement sur JS et Python, et enfin l'alternative langage à accolades / à tabulation, je pense que Python aurait un grand succès si enfin quelqu'un pouvait finir l'effort de le porter en front, web et mobile natif. Flutter/Dart n'a pas eu le succès escompté (pas assez) donc ...allo Google svp? Le créateur de Python et ''dictateur bienveillant à vie'' , Guido van Rossum, était chez Google, dommage...maintenant chez Microsoft, qui n'est pas un leader du front, et a son Transcript, difficile de créer un concurrent interne... Dommage.

[Fagus]

... je pense que Python aurait un grand succès si enfin quelqu'un pouvait finir l'effort de le porter en front, web et mobile natif. Flutter/Dart n'a pas eu le succès escompté (pas assez) ...

ça existe, j'avais fait un calculateur en brython, sans raison particulière à part que ça me facilitait la vie. Ce n'est pas aussi bien que typescript car c'est transpilé en js dans le navigateur. Le débogage c'est sommaire mais j'ai pas eu de soucis pour un projet très simple. il y a Transcrypt aussi mais je n'ai pas testé.

Pour le mobile, brython + cordova ça marche et ça reste léger. Pour le mobile natif je ne pense pas que ça existera. Il y a des compilateurs de python mais les binaires sont très lourds et intègrent l'interpréteur. Le gain existe, mais autant utiliser dart. D'ailleurs il existe des bindings de flutter vers d'autres langages dont python (en gros ça charge un interpréteur de python + la machine de dart + une communication entre les 2 + le runtime de flutter ...)

[boboss123]

Par curiosité, j'ai testé une compilation : pour afficher un simple "hello world!", le fichier ".wasm" fait 4Mo, donc pas très adapté pour certaines applications.

[Meiyo40]

Par curiosité, j'ai testé une compilation : pour afficher un simple "hello world!", le fichier ".wasm" fait 4Mo, donc pas très adapté pour certaines applications.

Le soucis de go c'est qu'il faut emporter son runtime(GC).
Contrairement à C/Rust qui sont plus léger à ce niveau par exemple.

[dolanor]

Par curiosité, j'ai testé une compilation : pour afficher un simple "hello world!", le fichier ".wasm" fait 4Mo, donc pas très adapté pour certaines applications.

C'est possible d'utiliser tinygo (http://tinygo.org) pour réduire l'output du webassembly. En effet celui par défaut de Go est assez massif (car runtime (garbage collection + scheduler goroutines) et symboles de debug, etc). C'est un avantage pour du dev back, pour pouvoir débugger sans perdre de perf sur le fonctionnement en prod.

Mais pour du front, tinygo peut faire l'affaire. C'est un transpilateur qui analyse les sources avec le code de la standard lib, récupère l'AST Go, et le transforme en AST compatible LLVM. Ensuite, c'est juste llvm qui compile en .wasm. Ça peut réduire TRÈS fortement. Par contre, le runtime inclus est beaucoup plus light et n'a pas toutes les fonctionnalités de langage ni le support complet de la std lib Go. Mais franchement, ça fait déjà énormément. (j'avais suivi un tuto à l'époque et ça donnait ça :https://github.com/dolanor/drawasm )

Par contre, je n'ai pas les même chiffres:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
dolanor@mine:/tmp/mainwasm$ ls -lh
total 7,7M
-rw-rw-r-- 1 dolanor dolanor   27 févr.  4 14:33 go.mod
-rw-rw-r-- 1 dolanor dolanor   54 févr.  4 14:35 main.go
-rwxrwxr-x 1 dolanor dolanor 1,5M févr.  4 14:34 mainwasm
-rwxrwxr-x 1 dolanor dolanor 2,2M févr.  4 14:35 mainwasm-fmt
-rwxrwxr-x 1 dolanor dolanor 2,4M févr.  4 14:35 mainwasm-fmt.wasm
-rwxrwxr-x 1 dolanor dolanor 1,6M févr.  4 14:36 mainwasm.wasm
dolanor@mine:/tmp/mainwasm$ file *
go.mod:            ASCII text
main.go:           C source, ASCII text
mainwasm:          ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=6a2c8d549a366b401a3dbefca273b25c0b9d2c69, with debug_info, not stripped
mainwasm-fmt:      ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0d402edc5d65ee7a7bad67f4b6fd29139e083ed2, with debug_info, not stripped
mainwasm-fmt.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
mainwasm.wasm:     WebAssembly (wasm) binary module version 0x1 (MVP)

Donc entre 1.6 Mo pour un println("Hello World") et 2.4 Mo pour un fmt.Println("Hello World") en webassembly.

Et sincèrement, avec le web moderne, combien on télécharge de bundle minifié de javascript/typescript minifié splitté en 30 dépendances de 100Ko minimum? Au final, ça pèse également.
Et puis, on rajoute une galerie d'image, et l'appli en .wasm en cache est déjà rentabilisée. Mais c'est vrai que ça ralentit le premier chargement, ce qui n'est pas génial.

[dolanor]

Est-ce que tout langage back a un intérêt à devenir front pour ce type de raison ? Manque de librairies front et d'outils, mais aussi culture front différente de la culture back chez les ingénieurs , ce n'est pas la même chose...
Cela dit le succès inverse de JS passé du front au back avec Node a montré sa pertinence.

En fait, Go a une réputation de langage Back uniquement, mais c'est un langage de programmation généraliste à la base. Principalement pensée pour les architectures modernes de CPU avec multi core. Les goroutines sont une conséquence de ce design.
Mais il n'y a pas que les serveurs de backend qui peuvent tirer de ces avantages. Les jeux vidéos me viennent en tête, vu le nombre de choses qui doivent être calculées pour la création d'une image. Avec des goroutines et des channels, ont peut gérer la simulation physique, l'IA du jeu, la gestion des ressources, des NPC, de l'état du jeu, des messages réseaux, et synchroniser tout ça avant la création d'une image à afficher sur le GPU. Et évidemment, sur du jeu multijoueur, un serveur en Go fait très sens avec sa bonne gestion du réseau et de la concurrence.

Perso, j'essaye de faire sortir Go de son côté backend uniquement. Le frontend web (même si j'ai plutôt tendance à lorgner du côté de HTMX dernièrement), moteur de jeu 3D et 2D, app en GUI (sans électron), app mobile, etc.
Et au moins, le langage est plutôt pas mal en terme de maintenance et sécurité **sifflote** ( https://nesbitt.io/2026/02/03/incide...024-yikes.html )

(Par contre, je suis un gros afficionado du Go, n'hésitez pas à prendre mon point de vue avec des pincettes. Et j'ai bossé chez Dagger (mais pas sur cette partie là))

[Meiyo40]

En fait, Go a une réputation de langage Back uniquement, mais c'est un langage de programmation généraliste à la base. Principalement pensée pour les architectures modernes de CPU avec multi core. Les goroutines sont une conséquence de ce design.
Mais il n'y a pas que les serveurs de backend qui peuvent tirer de ces avantages. Les jeux vidéos me viennent en tête, vu le nombre de choses qui doivent être calculées pour la création d'une image. Avec des goroutines et des channels, ont peut gérer la simulation physique, l'IA du jeu, la gestion des ressources, des NPC, de l'état du jeu, des messages réseaux, et synchroniser tout ça avant la création d'une image à afficher sur le GPU. Et évidemment, sur du jeu multijoueur, un serveur en Go fait très sens avec sa bonne gestion du réseau et de la concurrence.

Perso, j'essaye de faire sortir Go de son côté backend uniquement. Le frontend web (même si j'ai plutôt tendance à lorgner du côté de HTMX dernièrement), moteur de jeu 3D et 2D, app en GUI (sans électron), app mobile, etc.
Et au moins, le langage est plutôt pas mal en terme de maintenance et sécurité **sifflote** ( https://nesbitt.io/2026/02/03/incide...024-yikes.html )

(Par contre, je suis un gros afficionado du Go, n'hésitez pas à prendre mon point de vue avec des pincettes. Et j'ai bossé chez Dagger (mais pas sur cette partie là))

Si tu peux faire du gamedev en go, ce n'est pas un langage hyper adapté. Les Goroutines ont assez peu d'intérêt face aux threads, on rencontre déjà pas mal de problème avec les threads par ailleurs c'est très difficile de bien multithreader un jeu (la gameloop est fondamentalement single thread, on ne peut pas tout déporter), Goroutine + channel c'est puissant pour de l'I/O, mais beaucoup moins dans le cas d'un système compute heavy (CPU) où un thread devient plus intéressant, le scheduler de go deviendra un défaut et non un avantage dans ce cas.

Tu peux exclure go pour un jeu poussée où la stabilité et les performances doivent être maximisé, à cause de son GC difficile à gérer (les allocations).

A choisir je ferais du C# en gamedev (si le C++ est réellement inenvisageable), c'est extrêmement performant, très simple à prendre en main avec un écosystème et une communauté riche.

Go n'est pas mauvais mais on tombé dans le cas "du bon outil pour le bon projet", et si on parle compétitif/performance, go n'est pas adapté aux contraintes.

[boboss123]

C'est possible d'utiliser tinygo (http://tinygo.org) pour réduire l'output du webassembly. En effet celui par défaut de Go est assez massif (car runtime (garbage collection + scheduler goroutines) et symboles de debug, etc). C'est un avantage pour du dev back, pour pouvoir débugger sans perdre de perf sur le fonctionnement en prod.

Mais pour du front, tinygo peut faire l'affaire. C'est un transpilateur qui analyse les sources avec le code de la standard lib, récupère l'AST Go, et le transforme en AST compatible LLVM. Ensuite, c'est juste llvm qui compile en .wasm. Ça peut réduire TRÈS fortement. Par contre, le runtime inclus est beaucoup plus light et n'a pas toutes les fonctionnalités de langage ni le support complet de la std lib Go. Mais franchement, ça fait déjà énormément. (j'avais suivi un tuto à l'époque et ça donnait ça :https://github.com/dolanor/drawasm )

Par contre, je n'ai pas les même chiffres:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
dolanor@mine:/tmp/mainwasm$ ls -lh
total 7,7M
-rw-rw-r-- 1 dolanor dolanor   27 févr.  4 14:33 go.mod
-rw-rw-r-- 1 dolanor dolanor   54 févr.  4 14:35 main.go
-rwxrwxr-x 1 dolanor dolanor 1,5M févr.  4 14:34 mainwasm
-rwxrwxr-x 1 dolanor dolanor 2,2M févr.  4 14:35 mainwasm-fmt
-rwxrwxr-x 1 dolanor dolanor 2,4M févr.  4 14:35 mainwasm-fmt.wasm
-rwxrwxr-x 1 dolanor dolanor 1,6M févr.  4 14:36 mainwasm.wasm
dolanor@mine:/tmp/mainwasm$ file *
go.mod:            ASCII text
main.go:           C source, ASCII text
mainwasm:          ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=6a2c8d549a366b401a3dbefca273b25c0b9d2c69, with debug_info, not stripped
mainwasm-fmt:      ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0d402edc5d65ee7a7bad67f4b6fd29139e083ed2, with debug_info, not stripped
mainwasm-fmt.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
mainwasm.wasm:     WebAssembly (wasm) binary module version 0x1 (MVP)

Donc entre 1.6 Mo pour un println("Hello World") et 2.4 Mo pour un fmt.Println("Hello World") en webassembly.

Et sincèrement, avec le web moderne, combien on télécharge de bundle minifié de javascript/typescript minifié splitté en 30 dépendances de 100Ko minimum? Au final, ça pèse également.
Et puis, on rajoute une galerie d'image, et l'appli en .wasm en cache est déjà rentabilisée. Mais c'est vrai que ça ralentit le premier chargement, ce qui n'est pas génial.

ça reste beaucoup trop gros pour mon utilisation : j'ai besoin développer des interfaces de configuration d'équipement en embarqué, les pages Web doivent faire moins de 250ko (objectif que j'arrive à atteindre avec html/css/js/svg/png gzipés : j'ai une trentaine de vues avec des tableaux, formulaires, bargraphes, jauges et dessin de l'équipement. En lib externes, j'utilise uniquement Jquery et bootstrap : tout le reste est du code maison).

[boboss123]

En fait, Go a une réputation de langage Back uniquement, mais c'est un langage de programmation généraliste à la base. Principalement pensée pour les architectures modernes de CPU avec multi core. Les goroutines sont une conséquence de ce design.
Mais il n'y a pas que les serveurs de backend qui peuvent tirer de ces avantages. Les jeux vidéos me viennent en tête, vu le nombre de choses qui doivent être calculées pour la création d'une image. Avec des goroutines et des channels, ont peut gérer la simulation physique, l'IA du jeu, la gestion des ressources, des NPC, de l'état du jeu, des messages réseaux, et synchroniser tout ça avant la création d'une image à afficher sur le GPU. Et évidemment, sur du jeu multijoueur, un serveur en Go fait très sens avec sa bonne gestion du réseau et de la concurrence.

Perso, j'essaye de faire sortir Go de son côté backend uniquement. Le frontend web (même si j'ai plutôt tendance à lorgner du côté de HTMX dernièrement), moteur de jeu 3D et 2D, app en GUI (sans électron), app mobile, etc.
Et au moins, le langage est plutôt pas mal en terme de maintenance et sécurité **sifflote** ( https://nesbitt.io/2026/02/03/incide...024-yikes.html )

(Par contre, je suis un gros afficionado du Go, n'hésitez pas à prendre mon point de vue avec des pincettes. Et j'ai bossé chez Dagger (mais pas sur cette partie là))

Tu as déjà developpé des application mobiles ? Tu utilises quoi pour le frontend ?
... j'avais testé rapidement go+fyne, mais lorsque je lançais l'application dans le simulateur d'android studio, l'application ne se lançait pas donc j'ai laissé tombé, c'était juste pour tester pour faire un projet perso de jeu mobile simple (j'ai passé moins de 2H dessus).

[nhugodot]

En fait, Go a une réputation de langage Back uniquement, mais c'est un langage de programmation généraliste à la base. Principalement pensée pour les architectures modernes de CPU avec multi core. Les goroutines sont une conséquence de ce design.
Mais il n'y a pas que les serveurs de backend qui peuvent tirer de ces avantages. Les jeux vidéos me viennent en tête, vu le nombre de choses qui doivent être calculées pour la création d'une image. Avec des goroutines et des channels, ont peut gérer la simulation physique, l'IA du jeu, la gestion des ressources, des NPC, de l'état du jeu, des messages réseaux, et synchroniser tout ça avant la création d'une image à afficher sur le GPU. Et évidemment, sur du jeu multijoueur, un serveur en Go fait très sens avec sa bonne gestion du réseau et de la concurrence.

Perso, j'essaye de faire sortir Go de son côté backend uniquement. Le frontend web (même si j'ai plutôt tendance à lorgner du côté de HTMX dernièrement), moteur de jeu 3D et 2D, app en GUI (sans électron), app mobile, etc.
Et au moins, le langage est plutôt pas mal en terme de maintenance et sécurité **sifflote** ( https://nesbitt.io/2026/02/03/incide...024-yikes.html )

(Par contre, je suis un gros afficionado du Go, n'hésitez pas à prendre mon point de vue avec des pincettes. Et j'ai bossé chez Dagger (mais pas sur cette partie là))

Youpi,. Enfin du HTMX, alors, qu'en dis tu, pro et cons stp ? Sur Django, je crois qu'on a ainsi la stack la plus productive qui soit (pour faire un SaaS , pas un jeux évidemment), avec Claude code en sus par exemple. Et hop, dehors l'usine à gaz React (SvelteKit si besoin mais htmx et Alpine sont bien suffisants)

[dolanor]

ça reste beaucoup trop gros pour mon utilisation : j'ai besoin développer des interfaces de configuration d'équipement en embarqué, les pages Web doivent faire moins de 250ko (objectif que j'arrive à atteindre avec html/css/js/svg/png gzipés : j'ai une trentaine de vues avec des tableaux, formulaires, bargraphes, jauges et dessin de l'équipement. En lib externes, j'utilise uniquement Jquery et bootstrap : tout le reste est du code maison).

Ah, c'est sûr, à ce niveau là, je pense que c'est dur.
Même avec tinygo, mon module drawasm prend 589Ko (comparé au 2.4Mo du compilateur Go officiel.

Tu as déjà developpé des application mobiles ? Tu utilises quoi pour le frontend ?
... j'avais testé rapidement go+fyne, mais lorsque je lançais l'application dans le simulateur d'android studio, l'application ne se lançait pas donc j'ai laissé tombé, c'était juste pour tester pour faire un projet perso de jeu mobile simple (j'ai passé moins de 2H dessus).

Ah, l'avantage, c'est que tu peux tester une grande partie de l'application SANS lancer d'émulateur. Tu lances à coup de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

go run .

sur ta machine, et tu peux tester. Il faut juste créer une fenêtre d'une taille ressemblant avec le ration d'écran mobile. Donc je n'ai jamais lancé d'émulateur. Et quand j'avais besoin de tester la partie vraiment mobile avec le hardware (accès caméra, GPS, etc), j'installais directement sur le téléphone à coup de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

adb install example.apk

Si tu peux faire du gamedev en go, ce n'est pas un langage hyper adapté. Les Goroutines ont assez peu d'intérêt face aux threads, on rencontre déjà pas mal de problème avec les threads par ailleurs c'est très difficile de bien multithreader un jeu (la gameloop est fondamentalement single thread, on ne peut pas tout déporter), Goroutine + channel c'est puissant pour de l'I/O, mais beaucoup moins dans le cas d'un système compute heavy (CPU) où un thread devient plus intéressant, le scheduler de go deviendra un défaut et non un avantage dans ce cas.

Tu peux exclure go pour un jeu poussée où la stabilité et les performances doivent être maximisé, à cause de son GC difficile à gérer (les allocations).

A choisir je ferais du C# en gamedev (si le C++ est réellement inenvisageable), c'est extrêmement performant, très simple à prendre en main avec un écosystème et une communauté riche.

Go n'est pas mauvais mais on tombé dans le cas "du bon outil pour le bon projet", et si on parle compétitif/performance, go n'est pas adapté aux contraintes.

Je pense comprendre une partie de ce que tu dis, mais je ne suis pas sûr d'être d'accord. Par contre, je n'ai pas assez d'expérience pour être sûr à 100% de ce que j'avance.

Mais mon intuition est qu'en vérité, il y a un avantage à utiliser des goroutines dans des cas de ce genre, même avec une gameloop single threadé.

Disons que notre gameloop est là pour générer les images du jeu (donc entre 30 et 60 FPS), entre le faire de manière itérative en single thread, et distribuer les sous-étapes qui sont indépendantes en goroutines distribuées sur plusieurs threads, je pense qu'il peut y avoir un avantage, sans trop de surcharge du scheduler et du garbage collection.

Pour le C# en gamedev, c'était clairement pas un langage fait pour à la base, mais il est devenu un langage pour cela notamment grâce à l'utilisation d'Unity. Et j'ai entendu beaucoup de problème de freeze d'unity, notamment lié au garbage collection du C# si je me rappelle bien. Je ne pense pas que le GC de Go ait quoique ce soit à envier en général, et il vient juste d'être amélioré en 1.26.
Quand mon jeu que j'ai commencé à coder commencera à avoir de la complexité et pourrait approcher un jeu commercial, je ferai mon retour d'XP.

Youpi,. Enfin du HTMX, alors, qu'en dis tu, pro et cons stp ? Sur Django, je crois qu'on a ainsi la stack la plus productive qui soit (pour faire un SaaS , pas un jeux évidemment), avec Claude code en sus par exemple. Et hop, dehors l'usine à gaz React (SvelteKit si besoin mais htmx et Alpine sont bien suffisants)

Perso, je l'utilise pour générer des panneau d'admin pour gérer mes données stockées sur mon service REST. Et pour le moment, j'en suis super content. C'est réactif, et je n'ai pas besoin de gérer 2 système d'état. Ce qui est affiché par l'HTML est l'état du serveur, pas besoin d'état intermédiaire transmis via JSON qui ensuite il faut mettre en place/formatter au format HTML. Je trouve que ça réduit la complexité de manière incroyable. Sans compter les problèmes de synchro entre l'état serveur et l'état local/javascript. Le javascript de HTMX est quasiment là juste pour pouvoir envoyer des requêtes en PUT, DELETE vu que HTML5 ne supporte toujours pas ça en natif dans les formulaire HTML.

Pour moi, le javascript devait être là pour rendre les pages dynamiques, en terme appli interactives. Pas pour faire des formulaires et gérer des choses basiques dans le front.

[nhugodot]

Ah, c'est sûr, à ce niveau là, je pense que c'est dur.
Même avec tinygo, mon module drawasm prend 589Ko (comparé au 2.4Mo du compilateur Go officiel.

je ne vous comprends pas: dans tous les cas vous lancez le navigateur, obèse: vous ne faites qu'occulter un problème: le "runtime" web HTML/CSS est lourd aussi, tout comme vous critiqueriez le runtime Flutter, Java, Wasm, ... Le plus optimisé est toujours de n'utiliser que "juste ce dont j'ai besoin" pour votre cas, sur l'OS directement, voire sans OS, même... Quand on voit ce que pèse une messagerie comme Whatsapp versus iChat/iMessage sur McOSX, voire gmail vs Mail... et si même on prend en compte toute la pile OS sous votre app, autant choisir un GNU ultra light sans même fenêtrage (sinon, Puppy Linux): là ok on optimise tout.

Mais comme on disait encore il y a un an: le temps développeur coute plus que la machine, donc on choisit une stack obèse mais facile, productive.

Avec l'ère des IA codeuse, on change à nouveau d'ère: le codage ne coute plus rien... (et le coût de la RAM augmente... à cause de ces LLM justement! Drôle de retour de bâton, non?). Va falloir demander à Claude Code de coder en C optimisé pour un OS bien minimal, tiens ... DOS/x86? RiscOS/ARM? Quid sur Risc-V?

[dolanor]

je ne vous comprends pas: dans tous les cas vous lancez le navigateur, obèse: vous ne faites qu'occulter un problème: le "runtime" web HTML/CSS est lourd aussi, tout comme vous critiqueriez le runtime Flutter, Java, Wasm, ... Le plus optimisé est toujours de n'utiliser que "juste ce dont j'ai besoin" pour votre cas, sur l'OS directement, voire sans OS, même... Quand on voit ce que pèse une messagerie comme Whatsapp versus iChat/iMessage sur McOSX, voire gmail vs Mail... et si même on prend en compte toute la pile OS sous votre app, autant choisir un GNU ultra light sans même fenêtrage (sinon, Puppy Linux): là ok on optimise tout.

Mais comme on disait encore il y a un an: le temps développeur coute plus que la machine, donc on choisit une stack obèse mais facile, productive.

Avec l'ère des IA codeuse, on change à nouveau d'ère: le codage ne coute plus rien... (et le coût de la RAM augmente... à cause de ces LLM justement! Drôle de retour de bâton, non?). Va falloir demander à Claude Code de coder en C optimisé pour un OS bien minimal, tiens ... DOS/x86? RiscOS/ARM? Quid sur Risc-V?

Ah, mais je suis totalement d'accord avec toi. Dernièrement, j'essaye d'éviter le web quand je peux éviter. La RAM de mon PC est bouffée par tous mes onglets, des onglets qui prennent 300Mo, c'est de la folie.
Bref, du natif, dès que ça fait sens, du web, dès que ça fait sens.

L'avantage indéniable du web, c'est que tout le monde à un navigateur, donc pour être accessible (dans le sens disponible. Rendre une page web accessible ce n'est pas évident), c'est top. Mais faire installer des "app" qui ne sont que des front end electron pour appli web, ça m'énerve.

[nhugodot]

Ah, mais je suis totalement d'accord avec toi. Dernièrement, j'essaye d'éviter le web quand je peux éviter. La RAM de mon PC est bouffée par tous mes onglets, des onglets qui prennent 300Mo, c'est de la folie.
Bref, du natif, dès que ça fait sens, du web, dès que ça fait sens.

L'avantage indéniable du web, c'est que tout le monde à un navigateur, donc pour être accessible (dans le sens disponible. Rendre une page web accessible ce n'est pas évident), c'est top. Mais faire installer des "app" qui ne sont que des front end electron pour appli web, ça m'énerve.

On n'avait pas java, "code once run everywhere", y'a 30 ans, sur des PC à... 4Mo de RAM? Ahahaha, aujourd'hui ça ferait gadget, et pourtant, qui dit mieux, un truc qui marche partout et n'a pas besoin de tout le bousin d'un navigateur obèse pour servir une fonctionnalité?

Allez, Copilot: "- La solution la plus économe en RAM pour une app multiplateforme reste :
→ une application native minimaliste + un moteur partagé en Rust/C++ + une fine couche UI par plateforme. 30-80Mo
- La deuxième meilleure option en RAM :
→ Flutter, bien plus léger qu’une web‑app, mais plus lourd qu’un vrai natif. 80-150Mo
- La pire option en RAM :
→ WebView / PWA / app web, qui consomme massivement (200–500 Mo) même pour une messagerie simple.

Java: interdit sur iOS... et 150-300Mo d'overhead. Bon, Flutter est le Java moderne, quoi...


WASM : combien de RAM en pratique ?
Pour une app type messagerie :
- WASM dans un navigateur → 80–200 Mo
(car il tourne dans le moteur JS + sandbox + runtime WASM)
- WASM dans un runtime standalone (Wasmtime, Wasmer) → 40–120 Mo
(plus léger, mais pas encore universel sur mobile)
Conclusion : WASM n’est pas aussi léger que du natif, mais plus léger qu’une web‑app.

2) Pourquoi WASM n’est pas ultra‑léger
- Le runtime WASM doit gérer une mémoire linéaire, souvent pré‑allouée.
- Beaucoup de langages compilés vers WASM embarquent un mini‑runtime (GC, allocateurs).
- Dans un navigateur, WASM dépend du moteur JS pour les bindings → overhead.
- WASI n’est pas encore complet : pas de GUI, pas de sockets avancés, pas de threads partout.

3) WASI : promesse énorme, mais pas encore utilisable pour une messagerie multiplateforme
WASI vise à remplacer la JVM ou Node comme runtime universel.
Mais aujourd’hui :
- Pas de support graphique standard.
- Pas de support complet réseau (TCP/UDP).
- Pas de packaging mobile iOS/Android simple.
- Pas d’accès natif aux APIs système (notifications, stockage sécurisé, etc.).
Donc : impossible de faire une messagerie complète uniquement en WASI en 2026.

5) Quand WASM/WASI devient intéressant
- Jeux 2D/3D portés depuis C++
- Modules cryptographiques
- Plugins sandboxés
- Extensions de navigateur
- Code portable serveur → edge computing (Cloudflare Workers, Fastly)
Mais pas encore pour une app complète avec UI + stockage + réseau.

6) Conclusion synthétique
- WASM/WASI n’est pas la solution la plus économe en RAM.
- C’est plus léger qu’une web‑app, mais plus lourd que du natif ou Flutter.
- WASI n’est pas encore prêt pour une messagerie multiplateforme complète."

...

Et sous windows 3.1 (voire Geoworks Ensemble, aaaah, souvenirs...) on savait faire en quelques centaines de Ko... et maintenant?
- Optimisation manuelle
→ On peut faire une messagerie moderne en 20–40 Mo de RAM.
→ En Rust/C++ + UI native, on peut descendre à 10–20 Mo.
Mais pas avec Flutter, React Native, Electron, WebView, Java, WASM.


Allez, amusons nous: et Pascal/Delphi, Livecode, etc.? Je découvre des perles inconnues, vous les connaissiez? Slint surtout?
"- Le seul vrai concurrent “léger” à Flutter aujourd’hui = Qt (C++: 40-120Mo) ou Rust + Slint (20-50Mo.
- Le seul concurrent “léger + moderne + productif” = Kotlin Multiplatform + UI native. 30-80Mo de RAM
- Les solutions Pascal/Delphi (via FMX, 20-50Mo) sont plus légères que Flutter (80-150Mo), mais vieillissantes.
- WinDev, LiveCode, MAUI → trop lourds.
"

ps: coder en Pascal, j'adorais... , dommage que, comme Smalltalk (et Eiffel, Ada, etc.) ce ne soit pas "libre", free... et que la masse des devs préfère un truc dégueu mais gratos (Java, JS, PHP, ...) que payant mais bien foutu, propre, beau, efficace... Merci à Google de nous avoir offert Go et Dart...

En Golang multi cibles (windows mac gnu ios et android), avec une UI, y'a Fyne (UI "toolkit) et Gio (UI "game engine"), 50-120Mo, similaire à Flutter donc... Gio est le plus léger, puis Fyne, puis Flutter.
Go + Fyne/Gio:
Avantages :
- RAM plus faible que Flutter
- Binaire plus petit
- Simplicité du langage Go
- Démarrage ultra rapide
- Très bon pour des outils internes, UIs simples, apps desktop légères
Inconvénients :
- UI limitée
- Écosystème minuscule
- Mobile fragile
- Pas de web
- Pas de widgets avancés
- Pas de design system moderne

a) Fyne (Go UI multiplateforme)
- Site officiel : https://fyne.io
- Code source GitHub : https://github.com/fyne-io/fyne
- Documentation : https://developer.fyne.io
Notes rapides :
- Multiplateforme complet (Windows, macOS, Linux, Android, iOS).
- UI “toolkit” simple, stable, mais basique.
- RAM raisonnable (50–120 Mo).

b) Gio (Gio UI / Gio UI Toolkit)
- Site officiel : https://gioui.org
- Code source GitHub : https://github.com/gioui/gio
- Documentation : https://gioui.org/doc
Notes rapides :
- Rendu GPU moderne, style “Immediate Mode GUI”.
- Très léger (40–100 Mo).
- Très rapide, mais écosystème minuscule.
- Mobile supporté, mais fragile.


Verdict final
- Le meilleur pour dashboards modernes → Flutter
- Le meilleur pour dashboards légers → Slint
- Le meilleur pour dashboards minimalistes → Go + Gio
- Le plus simple mais limité → Go + Fyne


qui veut tester?

[boboss123]

Ah, c'est sûr, à ce niveau là, je pense que c'est dur.
Même avec tinygo, mon module drawasm prend 589Ko (comparé au 2.4Mo du compilateur Go officiel.



Ah, l'avantage, c'est que tu peux tester une grande partie de l'application SANS lancer d'émulateur. Tu lances à coup de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

go run .

sur ta machine, et tu peux tester. Il faut juste créer une fenêtre d'une taille ressemblant avec le ration d'écran mobile. Donc je n'ai jamais lancé d'émulateur. Et quand j'avais besoin de tester la partie vraiment mobile avec le hardware (accès caméra, GPS, etc), j'installais directement sur le téléphone à coup de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

adb install example.apk

Je pense comprendre une partie de ce que tu dis, mais je ne suis pas sûr d'être d'accord. Par contre, je n'ai pas assez d'expérience pour être sûr à 100% de ce que j'avance.

Mais mon intuition est qu'en vérité, il y a un avantage à utiliser des goroutines dans des cas de ce genre, même avec une gameloop single threadé.

Disons que notre gameloop est là pour générer les images du jeu (donc entre 30 et 60 FPS), entre le faire de manière itérative en single thread, et distribuer les sous-étapes qui sont indépendantes en goroutines distribuées sur plusieurs threads, je pense qu'il peut y avoir un avantage, sans trop de surcharge du scheduler et du garbage collection.

Pour le C# en gamedev, c'était clairement pas un langage fait pour à la base, mais il est devenu un langage pour cela notamment grâce à l'utilisation d'Unity. Et j'ai entendu beaucoup de problème de freeze d'unity, notamment lié au garbage collection du C# si je me rappelle bien. Je ne pense pas que le GC de Go ait quoique ce soit à envier en général, et il vient juste d'être amélioré en 1.26.
Quand mon jeu que j'ai commencé à coder commencera à avoir de la complexité et pourrait approcher un jeu commercial, je ferai mon retour d'XP.





Perso, je l'utilise pour générer des panneau d'admin pour gérer mes données stockées sur mon service REST. Et pour le moment, j'en suis super content. C'est réactif, et je n'ai pas besoin de gérer 2 système d'état. Ce qui est affiché par l'HTML est l'état du serveur, pas besoin d'état intermédiaire transmis via JSON qui ensuite il faut mettre en place/formatter au format HTML. Je trouve que ça réduit la complexité de manière incroyable. Sans compter les problèmes de synchro entre l'état serveur et l'état local/javascript. Le javascript de HTMX est quasiment là juste pour pouvoir envoyer des requêtes en PUT, DELETE vu que HTML5 ne supporte toujours pas ça en natif dans les formulaire HTML.

Pour moi, le javascript devait être là pour rendre les pages dynamiques, en terme appli interactives. Pas pour faire des formulaires et gérer des choses basiques dans le front.

Oui avant de compiler pour Android, j'ai testé mon application sur PC et ça fonctionne très bien : sur le simulateur d'android studio que ça ne fonctionne pas, quand j'ouvre l’application, ça me fait un écran noir, je n'ai pas cherché plus loin.
Et puis ça m'a soulé d'essayer d’installer le simulateur pour que ça fonctionne avec le binaire généré : la configuration n'était pas simple. Quand je fais un POC, je n'ai pas envie de passer des heures à configurer la toolchain.
Ce que j'aime bien sur Go (version PC), c'est que c'est super simple de faire de la cross-compilation... dommage que le langage n'intègre pas des outils pour ensuite faire des tests sur Android. Après reste aussi le soucis que ce n'est pas compatible iOS : je cherche un langage multiplateforme (PC/smartphone) permettant de faire des jeux en lignes basiques (tour par tour), c'est pour ça que ce qui me semble le plus simple semble être une app à base d'HTML/CSS/JS dans une Webview cross-plateform.

[Fagus]

...

Allez, Copilot: "- La solution la plus économe en RAM pour une app multiplateforme reste :
→ une application native minimaliste + un moteur partagé en Rust/C++ + une fine couche UI par plateforme. 30-80Mo
...

ps: coder en Pascal, j'adorais... , dommage que, comme Smalltalk (et Eiffel, Ada, etc.) ce ne soit pas "libre", free...
...
qui veut tester?

Bonjour,

quand je fais /usr/bin/time -v "mon app python en tkinter un peu moche mais fonctionnelle" ça me donne "Maximum resident set size (kbytes): 36588" (l'explorateur de processus dit 800k à 1Mo de Ram mais je suppose qu'il ne compte pas l'interpréteur python qui de toutes façons était déjà chargé par le système).
36Mo de Ram, c'est pas si moche pour une GUI multi plateforme de haut niveau "battle tested" qui s'ouvre instantanément sur un raspberry (versus plusieurs secondes à plus de 10 secondes pour une app. native compilée windows moderne optimisée par les armées d'ingé de microsoft...) sur une station de travail haut de gamme .

Sinon, pascal et smalltalk ça existe en top qualité et en libre (coquille ?) c'est Lazarus/freepascal et Pharo.

Pour donner tord à copilot en c/c++ il y a aussi fltk et IUP : multi plateformes et petits (mais faut pas trop en demander)

je cherche un langage multiplateforme (PC/smartphone) permettant de faire des jeux en lignes basiques (tout par tour), c'est pour ça que ce qui me semble le plus simple semble être une app à base d'HTML/CSS/JS.

Un moteur de jeu ?
Defold en lua pour du léger ?
Godot pour du un peu plus lourd ?

J'ai fait du sans framework, et c'est cool, mais je pense pas que je le referais (réinvention de l'eau tiède).

[dolanor]

Oui avant de compiler pour Android, j'ai testé mon application sur PC et ça fonctionne très bien : sur le simulateur d'android studio que ça ne fonctionne pas, quand j'ouvre l’application, ça me fait un écran noir, je n'ai pas cherché plus loin.
Et puis ça m'a soulé d'essayer d’installer le simulateur pour que ça fonctionne avec le binaire généré : la configuration n'était pas simple. Quand je fais un POC, je n'ai pas envie de passer des heures à configurer la toolchain.

Bizarre, faudra que je teste. En tout cas, "chez moi ça marche" sur 3 android récents différents.
Mais oui, la toolchain Android, c'est une PLAIE. T'as la bonne version de la lib, mais pas du framework, et puis pas la bonne version des tools. C'est extrêmement compliqué et fatiguant. Je te comprends.

Ce que j'aime bien sur Go (version PC), c'est que c'est super simple de faire de la cross-compilation... dommage que le langage n'intègre pas des outils pour ensuite faire des tests sur Android.

Comme dit, le plus proche de l'expérience cross compilation Go sur desktop, je l'ai trouvé avec l'outil `fyne` qui te sort un .apk après un simple `fyne package xxx`. Mais, ça fait écrire le programme avec fyne, évidemment. Mais globalement, la complexité de la plateforme sous-jacente (ici, android) et vraiment reléguée aux couches basses, et on gère principalement les couches haut niveaux qui devraient marcher sur toutes les plateformes de façon équivalentes.

Après reste aussi le soucis que ce n'est pas compatible iOS

Normalement, si, mais il faut une machine sur MacOS pour cela. La cage dorée Apple. Du coup, en effet, tu ne peux pas cross-compiler, vu qu'il te faut le matos et l'OS Apple pour cela.

je cherche un langage multiplateforme (PC/smartphone) permettant de faire des jeux en lignes basiques (tour par tour), c'est pour ça que ce qui me semble le plus simple semble être une app à base d'HTML/CSS/JS dans une Webview cross-plateform.

J'avais exactement les même besoins il y a quelques années, et au final, je me suis créé mon propre framework frontend en Go (transpilé en JS via GopherJS). Et, même si il n'est pas fini (j'ai été très occupé à coté), le bousin compile/fonctionne encore, presque 10 ans plus tard. Si j'étais parti avec Angular (1 à l'époque), je suis certains que je ne pourrais même pas l'utiliser.

Entre temps, j'ai manqué de temps, et GopherJS a perdu de la vitesse au profit du support de WebAssembly sur Go. Je n'ai pas encore tenté de le porter dessus depuis.

Mais sinon, j'ai appris l'existence de framework pour créer des jeux tour par tour en ligne via la plateforme boardgamearena : https://en.doc.boardgamearena.com/Studio
Ça te gère un maximum de choses, gestion des decks, du shuffles, des jetons, plateaux, etc. Du coup, tu as juste a implémenter ta logique de jeu.

Après, pour du Go, il y a https://ebitengine.org/ en moteur de jeu plutôt bien avancé, avec une communauté active, un projet dynamique avec un créateur qui a apporté pas mal (notamment purego, pour pouvoir executer des libs .so/.dll sans utiliser CGO, donc sans impacter le cross compile et sans trop perdre en perf). Et ça tourne sur du mobile et desktop et WebAssembly. Par contre, c'est 2D.

Un moteur de jeu ?
Defold en lua pour du léger ?
Godot pour du un peu plus lourd ?

pour de la 3D en Go, je regarde sur https://github.com/g3n/engine , mais le mainteneur principal est très occupé. Je vais tenter de récupérer des droits pour merger des PR. Et j'aimerais finaliser le support WebAssembly.

J'ai fait du sans framework, et c'est cool, mais je pense pas que je le referais (réinvention de l'eau tiède).

Pareil, au bout d'un moment, tu fais ton propre framework et tu perds du temps à implémenter des choses qui seraient potentiellement assez accessible sur un autre moteur. Toujours bon pour la connaissance, mais si tu veux vraiment finir ton projet, créer un framework te détourne du projet.