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

[marsupial]

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.