Wails : le pari de Golang sur les applications de bureau pour surpasser Electron

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 한국어 Português Русский 中文

컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00Wails est une technologie multiplateforme qui permet de créer des applications de bureau performantes en Go.

00:00:04On me l'a demandé énormément de fois sur la chaîne suite aux différentes vidéos comparatives

00:00:08sur les frameworks de bureau. Aujourd'hui, je vais donc vous montrer comment utiliser Wails pour créer des applications de bureau,

00:00:13et le comparer à des frameworks comme Electron et Tauri. Nous allons voir le développement

00:00:17d'un enregistreur d'écran pour bureau, comme dans d'autres vidéos, et comparer la taille des fichiers,

00:00:22les performances et l'expérience développeur. Wails est totalement nouveau pour moi,

00:00:27nous allons donc découvrir ça ensemble. Wails fonctionne de manière très similaire à Tauri, mais

00:00:36le backend est écrit en Go plutôt qu'en Rust. Vous développez l'interface frontend dans une webview avec des technologies web,

00:00:41qui appelle ensuite des API natives gérées par Golang. Cela signifie que vous pouvez compiler une application

00:00:47compatible à la fois avec Mac et Windows. Contrairement à Electron, Wails n'embarque pas de navigateur.

00:00:52Il réutilise le moteur de rendu natif de chaque plateforme, tout comme Tauri. La taille de l'exécutable

00:00:58devrait théoriquement être bien plus réduite, mais nous le vérifierons plus tard lors du comparatif.

00:01:03Si vous aimez ce genre de contenu, abonnez-vous pour en voir plus. Voici l'outil d'enregistrement

00:01:07d'écran que j'ai développé avec Wails, et que j'ai aussi réalisé avec Electron et Tauri.

00:01:12On sélectionne l'écran à enregistrer. On clique sur enregistrer. On peut bouger la souris. L'application

00:01:16de bureau n'apparaîtra pas dans l'enregistrement. J'appuie sur stop. Et voici l'écran que je viens

00:01:21d'enregistrer. Je peux couper la vidéo si je veux, puis cliquer sur exporter en MP4 pour sauvegarder la vidéo

00:01:27directement sur mon ordinateur. Si l'on regarde la structure de ce projet, c'est très similaire

00:01:32à ce à quoi on s'attendrait avec Electron. On a tous les fichiers frontend dans un dossier frontend,

00:01:36puis le fichier d'entrée. Dans ce cas, c'est un fichier Go nommé main.go, et à l'intérieur,

00:01:41on retrouve une fonction main. Là encore, c'est similaire à Electron, et on peut y déclarer

00:01:47des éléments comme le titre, la largeur, la hauteur, la couleur de fond, ainsi que des paramètres

00:01:52spécifiques à Mac. Si vous voulez des comportements différents entre Mac et Windows, c'est tout à fait

00:01:57possible. Maintenant, si on regarde dans le dossier frontend, sous source, on retrouve tout

00:02:02le code React. Dans app.tsx, il s'agit de code React standard, sauf qu'on appelle

00:02:09des API définies du côté de Go. Si on regarde cet import API et ses utilisations dans

00:02:16le fichier, vous voyez qu'on utilise API.onrecording finished, onrecording failed, start recording, et cette API

00:02:22est générée automatiquement par Wails. En observant l'API elle-même, on voit que toutes les fonctions

00:02:27principales proviennent de ce fichier wails.js/go/main/app. Et si on regarde à l'intérieur,

00:02:33on constate que ce fichier est généré automatiquement. Il y a du gallois en haut et de l'anglais,

00:02:39tout simplement parce que le créateur de Wails est gallois. On y trouve toutes ces fonctions

00:02:43comme export video, list sources, request screen access, tout ce dont on a besoin pour

00:02:49un outil d'enregistrement d'écran. Si on passe côté Go dans le fichier app.go et qu'on commente

00:02:54list sources avant d'enregistrer, on obtient soudainement une erreur dans API.ts, car

00:02:59list sources n'existe plus. C'est parce que nous exécutons wails.dev. Dès qu'une modification survient

00:03:05dans le fichier Go, cela régénère automatiquement les définitions TypeScript. Si on revient en arrière et qu'on

00:03:11décommente la ligne, l'erreur disparaît et l'application de bureau se recharge

00:03:16parce que les changements du côté Go, c'est-à-dire le backend, recompilent et rafraîchissent

00:03:23automatiquement l'application. Faisons maintenant quelques comparaisons pour voir les différences entre ces trois frameworks.

00:03:27Regardons d'abord la taille des fichiers. Wails pèse 52 mégaoctets, Tauri 57 mégaoctets et Electron,

00:03:34sans surprise, 324 mégaoctets. Wails et Tauri sont nettement plus légers, car ils

00:03:41n'embarquent pas Chromium, ce qui est logique. Cependant, en utilisant la webview native

00:03:47de chaque plateforme comme le font Wails et Tauri, vous risquez davantage d'observer des différences selon l'OS.

00:03:51C'est beaucoup moins problématique aujourd'hui, mais gardez-le en tête. En résumé, Tauri et

00:03:57Wails produisent des résultats similaires en termes de taille, car les deux frameworks

00:04:02sont conçus de la même manière, bien qu'ils utilisent des technologies sous-jacentes très différentes.

00:04:07Jetons un œil au temps de démarrage. Comme dans mes vidéos précédentes sur les apps de bureau,

00:04:12nous allons lancer chaque application 10 fois et faire la moyenne. Wails atteint 395

00:04:18millisecondes, Tauri 410 millisecondes et Electron 350 millisecondes. Pour les démarrages à froid où

00:04:26le cache est vidé à chaque fois, Wails fait 2 337 ms, Tauri 2 049 ms et Electron est un peu plus rapide,

00:04:34affichant 1 890 ms. En ce qui concerne les performances, comme pour Tauri, les performances lors de l'enregistrement

00:04:40de l'écran sont bien meilleures qu'avec Electron. Cela est dû à l'utilisation du kit

00:04:45de capture natif de Mac, évitant le transfert de données via le bridge. Avec Electron, l'enregistrement se fait depuis

00:04:51la webview elle-même avant de passer les données au backend, ce qui engarde un léger surcoût.

00:04:56Théoriquement, vous pourriez utiliser le kit de capture natif en écrivant du code C personnalisé avec Electron,

00:05:02mais la méthode par défaut d'Electron est celle-ci, et c'est ce que nous comparons

00:05:06aujourd'hui. Intéressons-nous à l'expérience développeur, là où se trouve

00:05:11la plus grande différence. J'ai beaucoup aimé développer avec Wails, mais la partie consacrée à la capture

00:05:15d'écran n'était pas aussi simple qu'avec Tauri. J'ai dû écrire du code Objective-C pour accéder à ScreenCaptureKit,

00:05:21alors qu'avec Tauri, on reste entièrement en Rust. Rust dispose en effet d'un vaste écosystème

00:05:28de crates communautaires encapsulant les frameworks natifs d'Apple. Dans Tauri, j'ai juste intégré une crate appelée screen

00:05:33capture kit, et l'API d'enregistrement est restée du Rust classique. Go n'a rien de correct pour ScreenCaptureKit à ma

00:05:39connaissance, mais propose Cgo, un outil intégré à Go pour compiler du code C.

00:05:44Cela signifie qu'avec Go, vous écrivez du C natif dans un fichier .m, vous l'exposez sous forme de fonctions C simples,

00:05:50puis vous indiquez à Go quels frameworks Apple lier. On se retrouve donc à écrire du vrai Objective-C

00:05:56et à appeler les mêmes API Apple que la crate Rust, mais cette fois en gérant tout le code.

00:06:02Cela représente environ 450 lignes de code Objective-C que l'application Rust n'avait pas. Dans l'ensemble,

00:06:08j'ai une légère préférence pour Tauri. L'écosystème autour des crates Rust me semble meilleur,

00:06:14mais c'est avant tout une question de goût. Si vous aimez développer en Go, Wails est une excellente

00:06:18option, et si vous préférez Rust, optez pour Tauri. Toutefois, avec Wails, vous devrez parfois

00:06:24écrire du code natif car l'écosystème est moins établi. J'espère que cette vidéo vous a plu,

00:06:29n'hésitez pas à vous abonner pour d'autres contenus. Si vous souhaitez voir d'autres comparatifs

00:06:33sur les frameworks de bureau, comme celui où l'on a comparé Deno desktop à Electrobun, j'ai mis le lien de la vidéo juste

00:06:39ici. Merci beaucoup d'avoir regardé. C'était Warren de Betterstack,

00:06:43et je vous dis à la prochaine. Malheureusement, Milo a dit pas d'autres vidéos cette semaine,

00:06:49on se retrouve donc lundi.

00:06:50*musique*

Key Takeaway

Wails offre une alternative légère à Electron pour créer des applications de bureau en Go et React, produisant un binaire de 52 Mo grâce à l'utilisation des webviews natives, au prix d'un effort de développement accru en C pour interagir avec les API système.

Highlights

Wails génère des exécutables de 52 Mo, contre 57 Mo pour Tauri et 324 Mo pour Electron.
Wails et Tauri utilisent la webview native de chaque système d'exploitation au lieu d'embarquer un navigateur Chromium complet.
Le temps de démarrage moyen à chaud s'élève à 395 ms pour Wails, 410 ms pour Tauri et 350 ms pour Electron.
La modification des fichiers backend en Go déclenche la régénération automatique des types TypeScript côté frontend.
L'accès aux API macOS natives comme ScreenCaptureKit nécessite l'écriture de code Objective-C via Cgo dans Wails, alors que Tauri dispose d'une crate Rust dédiée.

Timeline

Présentation de Wails et fonctionnement de l'architecture

Wails associe un backend écrit en Go à une interface frontend exécutée dans une webview native.
Les applications compilées avec Wails fonctionnent sur macOS et Windows à partir d'une base de code unique.
L'absence d'un navigateur embarqué réduit directement la taille du fichier exécutable final.

Wails se positionne comme un framework multiplateforme combinant Go pour le traitement système et des technologies web pour l'interface utilisateur. Contrairement à Electron qui intègre Chromium, Wails s'appuie sur le moteur de rendu natif présent sur le système hôte. Cette approche technique permet de distribuer un enregistreur d'écran capable d'exporter directement des fichiers MP4 tout en évitant que l'application n'apparaisse dans la capture.

Structure du projet et intégration de l'API Go-TypeScript

Le projet sépare les composants React dans un dossier frontend et le point d'entrée Go dans main.go.
L'exécution de wails.dev génère automatiquement les liaisons TypeScript à chaque modification du code Go.
Le rechargement à chaud recompile le backend et rafraîchit l'interface lors des changements de code.

La configuration d'une application Wails ressemble à celle d'Electron, avec un fichier de configuration Go définissant les paramètres de la fenêtre comme le titre, la hauteur et la largeur. Le code React appelle les fonctions Go déclarées dans le backend via un fichier wails.js généré automatiquement. La suppression ou la modification d'une méthode Go déclenche immédiatement des erreurs de type dans TypeScript, garantissant une synchronisation constante entre les deux couches.

Comparatif des performances, de la taille et du démarrage

Le fichier binaire de Wails atteint 52 Mo, devançant Tauri (57 Mo) et Electron (324 Mo).
Electron affiche le temps de démarrage à chaud le plus rapide avec 350 ms, suivi par Wails à 395 ms et Tauri à 410 ms.
L'enregistrement d'écran via ScreenCaptureKit natif sur macOS surpasse les performances du bridge Electron.

L'absence de Chromium permet à Wails et Tauri d'offrir des tailles de fichiers nettement inférieures à Electron. En matière de démarrage à froid avec cache vidé, Electron enregistre 1 890 ms, Tauri 2 049 ms et Wails 2 337 ms. Pour le traitement de la vidéo, Wails surpasse Electron en sollicitant directement les kits de capture natifs du système, évitant le transfert lourd de données d'image entre la webview et le processus principal.

Évaluation de l'expérience développeur et écosystème

L'absence de bibliothèques Go pour ScreenCaptureKit impose l'écriture de 450 lignes de code Objective-C via Cgo.
Tauri bénéficie d'un écosystème de crates Rust plus étendu pour encapsuler les API natives Apple.
Le choix entre Wails et Tauri dépend principalement de la préférence de langage entre Go et Rust.

Bien que le développement avec Wails soit fluide, l'intégration de fonctionnalités matérielles spécifiques révèle un écosystème moins mûr que celui de Rust. Là où Tauri permet d'importer une crate pour gérer ScreenCaptureKit en Rust pur, Wails exige la création de fichiers .m en Objective-C natif reliés au code Go par Cgo. La décision d'adopter Wails repose donc sur l'expertise en Go de l'équipe et la disposition à gérer du code C natif quand cela s'avère nécessaire.

Community Posts

Write about this video