Arrêtez Electron, passez à Wails : applications desktop en Go en 2026

Si vous développez un outil interne, un client de base de données, un visualiseur de logs ou n'importe quelle application desktop de petite ou moyenne taille, construisez-la avec Wails plutôt qu'avec Electron. Wails associe un backend Go à la webview déjà fournie par le système d'exploitation, si bien qu'une application vide pèse environ 8 à 11 MB au lieu de 295 à 384 MB (benchmark Elanis, 2026). Vous conservez votre frontend web et remplacez Node par Go. L'IPC écrite à la main devient des bindings générés, et aucun Chromium n'est embarqué puisque l'OS fournit la webview. Wails ne gagne pas tous les benchmarks pour autant, et pour certaines applications, Electron reste le meilleur choix.

En bref

• La taille est l'avantage évident. Dans un benchmark CI d'applications vides, les builds Wails étaient 30 à 40 fois plus petits que les builds Electron sous Windows, macOS et Linux (benchmark Elanis, 2026).
• Mémoire et démarrage : pas de victoire nette. Wails consommait moins de mémoire sous macOS et Linux mais davantage sous Windows, et Electron démarrait plus vite sur les trois systèmes d'exploitation dans ce même benchmark.
• Les gains les plus importants sont structurels. Vous livrez un seul binaire Go, écrivez le backend avec la bibliothèque standard et les goroutines de Go, l'appelez via des bindings générés et typés, et n'exécutez pas Node dans la page.
• Vous ne courez plus après les versions majeures d'Electron. Electron publie une nouvelle version majeure toutes les 8 semaines et ne prend en charge que les trois dernières (Electron, 2026). Avec Wails, la webview est mise à jour en dehors de votre application : par le programme de mise à jour Evergreen WebView2 sous Windows (Microsoft Learn, 2026), par les mises à jour de macOS et par les paquets de votre distribution Linux.
• Electron reste le bon choix lorsque vous avez besoin d'un rendu Chromium identique partout, que vous dépendez de modules natifs Node ou que vous disposez déjà d'une large base de code Electron.

Qu'est-ce qu'Electron embarque dans chaque application ?

Chaque application Electron embarque son propre navigateur et son propre runtime JavaScript. La documentation d'Electron l'explique : « En intégrant Chromium et Node.js dans son binaire, Electron vous permet de maintenir une seule base de code JavaScript » pour toutes les plateformes (documentation Electron, 2026). Ce compromis avait du sens quand l'alternative consistait à maintenir trois bases de code natives. Il implique aussi que chaque application installée transporte une copie complète de Chromium.

Le modèle de processus vient lui aussi de Chromium. Il y a un processus principal qui exécute Node.js, plus « un processus de rendu distinct pour chaque BrowserWindow ouverte (et chaque contenu web intégré) » (modèle de processus Electron, 2026). La logique backend vit dans le processus principal, l'interface dans les processus de rendu, et vous les reliez avec des messages IPC écrits à la main.

Reste le calendrier de publication. « Le rythme d'Electron entre deux versions majeures est de 8 semaines », et seules les trois dernières versions majeures stables sont prises en charge (calendrier Electron, 2026). Electron 44.0.0 est passé en stable le 25 août 2026, avec Chromium M152 et Node v24.18.1. Electron 45 est prévu pour le 20 octobre 2026 (versions Electron, 2026). Pour que vos utilisateurs reçoivent les correctifs de sécurité de Chromium, vous devez continuer à publier de nouveaux builds à ce rythme.

Comment fonctionne Wails ?

Wails se présente comme « une alternative légère et rapide à Electron pour Go » (documentation Wails, 2026). Au lieu d'embarquer un navigateur, il « réutilise le moteur de rendu natif de la plateforme ». Le README l'annonce : « Utilise les moteurs de rendu natifs, pas de navigateur embarqué ! » (Wails sur GitHub, 2026). Le moteur dépend de l'OS :

• Windows affiche votre interface avec Microsoft WebView2.
• macOS l'affiche avec WebKit.
• Linux l'affiche avec WebKitGTK.

Une application Wails est « une application Go standard, avec un frontend webkit » (Comment fonctionne Wails, 2026). Votre frontend (React, Svelte, Vue ou HTML simple) est intégré au binaire Go avec //go:embed, si bien que toute l'application est livrée sous la forme d'un seul exécutable.

Le pont entre les deux moitiés est l'option Bind, qui « indique quelles méthodes de struct exposer au frontend ». Quand vous lancez wails dev, Wails lit ces méthodes et génère des wrappers JavaScript ainsi que des déclarations TypeScript. Votre frontend appelle les méthodes Go comme des fonctions asynchrones. Pour envoyer des données dans l'autre sens, Go émet des événements runtime que JavaScript écoute.

Wails v2 est la branche stable, avec la v2.14.0 publiée le 10 août 2026 (versions Wails, 2026). Le projet est sous licence MIT et compte environ 36 300 étoiles sur GitHub. Parmi les applications construites avec Wails figurent Tiny RDM, une interface graphique pour Redis qui compte environ 13 000 étoiles (Tiny RDM, 2026), et le client gRPC Wombat (vitrine Wails, 2026).

Wails vs Electron : l'application est-elle plus petite et plus légère ?

Beaucoup plus petite, mais pas toujours plus légère. Les meilleurs chiffres publics proviennent de la comparaison de frameworks web-to-desktop d'Elanis, qui compile une application vide dans chaque framework en mode release sur la CI GitHub et mesure la taille, la mémoire et le temps de démarrage. Elle a été mise à jour le 4 septembre 2026 (benchmark Elanis, 2026).

Source : Elanis web-to-desktop-framework-comparison, mis à jour le 2026-09-04. Application vide, build release, GitHub CI. Ne comparez les frameworks qu'au sein d'un même OS. Le README n'indique pas les versions des frameworks.

C'est sur la taille que Wails l'emporte sans discussion. Une application Wails vide est environ 35 fois plus petite qu'Electron sous Windows, 40 fois sous macOS et 33 fois sous Linux. Sur une connexion d'hôtel lente, 11 MB se téléchargent en quelques secondes alors que 384 MB prennent plusieurs minutes. L'écart s'accumule aussi quand chaque outil installé sur un portable transporte son propre Chromium.

La mémoire dépend du système d'exploitation. Sous macOS, Wails consommait environ 3,7 fois moins de mémoire qu'Electron. Sous Linux, environ 1,6 fois moins. Sous Windows, il en consommait davantage : environ 323 MB contre 278 MB pour Electron. Le benchmark ne détaille pas ce résultat, mais WebView2 utilise le moteur de Microsoft Edge, basé sur Chromium, et exécute ses propres processus de navigateur. Sous Windows, vous payez donc probablement encore un moteur Chromium en mémoire, même si vous n'en livrez pas.

Electron démarrait plus vite partout dans ce benchmark. Sous Windows, il se lançait en environ 206 ms contre 559 ms pour Wails. Sous macOS, l'écart était de 640 ms contre 1 740 ms. Sous Linux, les deux étaient proches : 204 ms contre 263 ms. Une application vide sur un runner de CI ne donne qu'une indication approximative et ne correspondra pas à ce que voient vos utilisateurs. Les données ne soutiennent pas pour autant l'idée que Wails démarre toujours plus vite.

Dernière réserve concernant Windows. Les applications Wails nécessitent le Microsoft WebView2 Runtime. Il est livré avec Windows 11, et Microsoft indique que « la grande majorité des appareils Windows 10 disposent déjà du WebView2 Runtime » (Microsoft Learn, 2026). Intégrer le bootstrapper couvre les autres cas et ajoute environ 150 KB (guide Windows de Wails, 2026). Si vous avez besoin d'un moteur figé, Microsoft prévient toutefois que « les binaires Fixed Version dépassent 250 MB et augmenteront d'autant la taille du paquet de votre application ». Cela efface l'essentiel de l'avantage de taille sous Windows.

À quoi ressemble le code Wails ?

Voici un petit visualiseur de logs que vous pourriez construire pour votre équipe : choisir un fichier de log, afficher les 200 dernières lignes, puis diffuser les nouvelles lignes au fur et à mesure de leur écriture. Il interroge aussi l'endpoint de santé d'un service. Tout s'exécute en Go, le frontend se contente de l'affichage.

Le côté Go est un simple struct avec des méthodes exportées. TailLog lit un fichier avec os et bufio. CheckHealth appelle un endpoint HTTP avec un timeout grâce à net/http, que couvre le cours HTTP. Le code ci-dessous compile avec Wails v2.14.0 :

example.gogo
// app.go
package main

import (
	"bufio"
	"context"
	"fmt"
	"net/http"
	"os"
	"sync"
	"time"
)

const tailLines = 200

type App struct {
	ctx        context.Context
	mu         sync.Mutex
	stopFollow context.CancelFunc
}

func NewApp() *App { return &App{} }

// startup is called by Wails once the app is running. Keep the context:
// runtime calls like EventsEmit need it.
func (a *App) startup(ctx context.Context) {
	a.ctx = ctx
}

// TailLog returns the last 200 lines of the log file at path.
func (a *App) TailLog(path string) ([]string, error) {
	f, err := os.Open(path)
	if err != nil {
		return nil, fmt.Errorf("open log: %w", err)
	}
	defer f.Close()

	lines := make([]string, 0, tailLines)
	sc := bufio.NewScanner(f)
	sc.Buffer(make([]byte, 0, 64*1024), 1024*1024) // allow long JSON log lines
	for sc.Scan() {
		if len(lines) == tailLines {
			lines = lines[1:]
		}
		lines = append(lines, sc.Text())
	}
	if err := sc.Err(); err != nil {
		return nil, fmt.Errorf("read log: %w", err)
	}
	return lines, nil
}

// CheckHealth calls a service's health endpoint and returns the status code.
func (a *App) CheckHealth(url string) (int, error) {
	ctx, cancel := context.WithTimeout(a.ctx, 3*time.Second)
	defer cancel()

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return 0, fmt.Errorf("build request: %w", err)
	}
	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		return 0, fmt.Errorf("health check %s: %w", url, err)
	}
	defer resp.Body.Close()
	return resp.StatusCode, nil
}

main intègre le frontend compilé et passe le struct à Bind. Wails v2 se trouve à l'adresse github.com/wailsapp/wails/v2 :

example.gogo
// main.go
package main

import (
	"embed"
	"log"

	"github.com/wailsapp/wails/v2"
	"github.com/wailsapp/wails/v2/pkg/options"
	"github.com/wailsapp/wails/v2/pkg/options/assetserver"
)

//go:embed all:frontend/dist
var assets embed.FS

func main() {
	app := NewApp()

	err := wails.Run(&options.App{
		Title:  "Log Viewer",
		Width:  1100,
		Height: 720,
		AssetServer: &assetserver.Options{
			Assets: assets,
		},
		OnStartup: app.startup,
		Bind:      []interface{}{app},
	})
	if err != nil {
		log.Fatal(err)
	}
}

Lancez wails dev et Wails génère frontend/wailsjs/go/main/App.js et App.d.ts. Les déclarations ressemblent à ceci :

example.tsts
export function TailLog(arg1: string): Promise<Array<string>>;
export function CheckHealth(arg1: string): Promise<number>;

Chaque méthode liée renvoie une Promise. Si la méthode Go renvoie une error non nil, la Promise est rejetée avec cette erreur. Le frontend utilise donc simplement await et try/catch :

example.tsts
import { TailLog, CheckHealth } from "../wailsjs/go/main/App";

async function openLog(path: string) {
  try {
    const lines = await TailLog(path);
    renderLines(lines);
  } catch (err) {
    showError(`Could not read ${path}: ${err}`);
  }
}

async function refreshStatus(url: string) {
  try {
    const status = await CheckHealth(url);
    setStatus(status === 200 ? "healthy" : `HTTP ${status}`);
  } catch (err) {
    setStatus(`down: ${err}`);
  }
}

Vous n'avez ni à synchroniser des noms de canaux ni à vérifier la forme des messages à la main. Modifiez la signature d'une méthode Go et la déclaration régénérée change avec elle : un build du frontend avec vérification des types signale alors les appels obsolètes.

Diffuser les nouvelles lignes avec les événements runtime

C'est pour suivre un fichier en direct que la concurrence de Go se révèle utile. FollowLog se positionne à la fin du fichier, puis une goroutine vérifie périodiquement l'arrivée de nouvelles lignes et envoie chacune d'elles au frontend avec runtime.EventsEmit. Ouvrir un autre fichier annule le suivi précédent :

example.gogo
// follow.go
package main

import (
	"bufio"
	"context"
	"fmt"
	"io"
	"os"
	"strings"
	"time"

	"github.com/wailsapp/wails/v2/pkg/runtime"
)

// FollowLog streams lines appended to path as "log:line" events.
func (a *App) FollowLog(path string) error {
	f, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("open log: %w", err)
	}
	if _, err := f.Seek(0, io.SeekEnd); err != nil {
		f.Close()
		return fmt.Errorf("seek log: %w", err)
	}

	a.mu.Lock()
	if a.stopFollow != nil {
		a.stopFollow()
	}
	ctx, cancel := context.WithCancel(a.ctx)
	a.stopFollow = cancel
	a.mu.Unlock()

	go a.follow(ctx, f)
	return nil
}

func (a *App) follow(ctx context.Context, f *os.File) {
	defer f.Close()

	r := bufio.NewReader(f)
	var partial strings.Builder
	ticker := time.NewTicker(500 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			for {
				chunk, err := r.ReadString('\n')
				partial.WriteString(chunk)
				if err != nil {
					break // no complete line yet, try again on the next tick
				}
				line := strings.TrimRight(partial.String(), "\r\n")
				runtime.EventsEmit(a.ctx, "log:line", line)
				partial.Reset()
			}
		}
	}
}

Côté frontend, abonnez-vous une seule fois avec EventsOn :

example.tsts
import { FollowLog } from "../wailsjs/go/main/App";
import { EventsOn } from "../wailsjs/runtime/runtime";

EventsOn("log:line", (line: string) => appendLine(line));

await FollowLog("/var/log/payments-api/app.log");

Avec Electron, vous écririez la même fonctionnalité avec fs dans le processus principal, un ipcMain.handle pour la lecture, un webContents.send pour chaque nouvelle ligne et un script preload exposant les deux via contextBridge. Avec Wails, il suffit d'un struct Go et d'un nom d'événement. Cette version ne gère pas la rotation des logs. Un suivi destiné à la production rouvrirait le fichier quand sa taille diminue.

Wails v3 modifie un peu la structure. Vous enregistrez des services dans application.Options.Services avec application.NewService(&LogService{}), et le frontend importe le code généré depuis un répertoire bindings au lieu de wailsjs (bindings Wails v3, 2026). Ce sont toujours les méthodes d'un type Go que le frontend appelle.

En quoi le modèle de sécurité diffère-t-il ?

La sécurité d'Electron repose sur une checklist, alors que Wails part d'une surface plus réduite. Le guide de sécurité d'Electron vous demande de laisser l'intégration Node désactivée pour le contenu distant (par défaut depuis la 5.0.0), de garder l'isolation de contexte activée (par défaut depuis la 12.0.0), de garder le sandboxing des processus activé (par défaut depuis la 20.0.0), de valider l'expéditeur de chaque message IPC, de définir une Content Security Policy et de n'exposer des API à la page que via contextBridge (sécurité Electron, 2026).

Ces valeurs par défaut sont bonnes aujourd'hui, mais chacune est un flag que votre code peut désactiver. Et comme chaque application embarque Chromium, une faille du navigateur reste dans votre application installée jusqu'à ce que vous publiiez une mise à jour construite sur un Electron corrigé.

Wails élimine plusieurs de ces points par conception. Il n'y a pas de Node.js dans la page, donc pas de nodeIntegration à mal configurer. La page reçoit vos méthodes Go liées plus l'API runtime de Wails, et rien d'autre de l'hôte. Elle ne peut ni lire des fichiers ni lancer des processus, sauf si l'une de vos méthodes le fait. Comme la webview appartient à l'OS, ses correctifs de sécurité arrivent par le runtime Evergreen WebView2 à mise à jour automatique sous Windows, par les mises à jour de macOS ou par les paquets de votre distribution Linux, et non par votre pipeline de publication. Si vous figez un runtime Fixed Version sous Windows, les correctifs redeviennent votre responsabilité.

Un risque subsiste. Chaque méthode liée est une API, et la page qui l'appelle peut afficher du contenu que vous ne maîtrisez pas. Dans le visualiseur de logs ci-dessus, TailLog accepte n'importe quel chemin. Si votre application affiche un jour du HTML non fiable, cela devient une primitive de lecture de fichiers. Validez les arguments en Go comme vous valideriez l'entrée d'un handler HTTP : limitez les chemins aux répertoires autorisés et les URL aux hôtes connus. Une CSP reste également importante, car la page peut toujours effectuer des requêtes réseau comme n'importe quelle page web.

Pour la question voisine de ce qu'une dépendance Node peut faire au moment de l'installation, consultez Go est-il plus sûr que Node.js face aux attaques de la chaîne d'approvisionnement ?.

Quels sont les inconvénients de Wails ?

Wails échange un navigateur embarqué contre trois webviews différentes, et cela a un coût. Microsoft indique qu'avec l'Evergreen WebView2 Runtime, vous devriez mettre en place des tests de compatibilité ascendante, car le moteur se met à jour sous votre application (Microsoft Learn, 2026). Sous macOS, vous ciblez WebKit, le moteur de Safari : testez-y donc tout CSS ou toute API web que vous n'avez vérifié que dans Chrome.

Linux est la plateforme la plus délicate. Le guide Linux de Wails liste des problèmes connus : l'événement vidéo ended ne se déclenche pas à cause d'un bug de WebKitGTK, vous pouvez voir « GStreamer element autoaudiosink not found », et « WebKit installe des gestionnaires de signaux qui interfèrent avec le mécanisme de récupération des panics de Go » (guide Linux de Wails, 2026). Il existe aussi une scission d'ABI. Debian 11, Ubuntu 20.04 et RHEL 8 à 9 nécessitent l'ancien WebKitGTK 4.0, vous devez donc choisir entre les build tags webkit2_41 et webkit2_40 (distributions prises en charge par Wails, 2026). Une issue v3 de février 2026 signale une fenêtre vide sous X11 avec Nvidia, contournée avec WEBKIT_DISABLE_DMABUF_RENDERER=1 (issue Wails #4985, 2026).

Autres coûts à connaître :

• La v2 ne gère qu'une seule fenêtre. Le guide de migration v3 indique que la v2 « ne prenait en charge qu'une seule fenêtre par application », alors que la v3 « introduit la prise en charge native de plusieurs fenêtres comme fonctionnalité centrale » (guide Wails v2 vers v3, 2026).
• La v3 est encore en bêta. La dernière version est la v3.0.0-beta.25 du 22 septembre 2026. Ses notes de version précisent : « L'API est stable, mais vous pourriez encore rencontrer des problèmes avant la version finale 3.0 » (versions Wails, 2026). Le guide de migration ajoute que « la v2 reste la version stable actuelle ».
• L'écosystème est plus restreint. Il y a moins de plugins, et quand vous tombez sur un bug inhabituel, il y a moins de chances que quelqu'un ait déjà documenté la solution.
• La documentation de migration est maigre. La page « from Electron » de la documentation v3 n'est pour l'instant qu'une page d'attente.

Et Tauri ?

Tauri est l'autre grand framework basé sur une webview. Il se présente comme « un framework pour construire des binaires minuscules et rapides pour toutes les grandes plateformes desktop et mobiles », utilise « la webview déjà disponible sur le système de chaque utilisateur » et dispose d'un backend en Rust (Tauri, 2026). Tauri 2.0 est passé en stable le 2 octobre 2024 (blog Tauri, 2024).

Dans le benchmark Elanis, Tauri produisait les builds les plus petits (environ 3 à 5 MB) et consommait le moins de mémoire sous Linux. Il avait aussi le démarrage le plus lent sur tous les OS, avec environ 30 secondes sur le runner CI Linux. Tauri et Wails partagent les mêmes compromis liés à la webview, le choix se résume donc surtout au langage du backend. Si votre équipe écrit du Rust, utilisez Tauri. Si elle écrit du Go, utilisez Wails.

Comment migrer une application Electron vers Wails ?

Conservez votre frontend et remplacez le processus principal. Wails n'a pas encore de guide officiel de migration depuis Electron, planifiez donc le travail en associant chaque élément d'Electron à son équivalent Go :

Un ordre pragmatique :

1. Déplacez le frontend tel quel. Pointez Wails vers la sortie de votre build Vite ou webpack existant. La plupart des composants n'ont pas besoin de changer. Seuls les points d'appel qui parlent à l'API preload doivent être modifiés, et l'étape 2 s'en charge.
2. Portez un canal IPC à la fois. Chaque ipcMain.handle devient une méthode Go. Supprimez l'entrée preload correspondante et faites pointer le point d'appel vers l'import généré.
3. Remplacez les messages push par des événements. Tout ce qui est envoyé avec webContents.send devient runtime.EventsEmit.
4. Refaites votre packaging. wails build compile « un binaire prêt pour la production », et des flags comme -nsis, -webview2 et -platform couvrent les installateurs, la stratégie WebView2 et les cibles croisées (CLI Wails, 2026). Le guide de signature couvre la notarisation macOS et SignTool sous Windows, y compris avec GitHub Actions.
5. Testez sur les trois webviews. Cette étape représente un travail nouveau par rapport à Electron, prévoyez donc du temps pour elle.

Le Go que vous écrivez à l'étape 2 relève surtout de la bibliothèque standard. Si os, net/http et encoding/json sont nouveaux pour vous, le cours HTTP et le cours sur les formats de données couvrent ce dont un backend desktop a besoin.

La place de LevelUpGo

Le visualiseur de logs ci-dessus s'appuie sur les fondamentaux de Go : fonctions, valeurs de retour multiples, gestion des erreurs et bibliothèque standard. Le cours Go Basics sur LevelUpGo les enseigne avec un véritable éditeur à côté de chaque leçon, et votre code doit passer les tests avant que vous puissiez avancer. Le travail avec les goroutines et context dans FollowLog est couvert dans Concurrency Fundamentals. Si vous voulez vous entraîner davantage, le Training Ground propose des exercices indépendants.

Si vous hésitez encore à investir du temps dans Go, commencez par Go vaut-il la peine d'être appris en 2026 ?. Pour savoir où Go tourne déjà en production, consultez Où Go est-il utilisé ?, et pour le côté serveur, Meilleur langage de programmation pour le développement backend.

Questions fréquentes

Wails est-il meilleur qu'Electron ?

Pour la plupart des applications desktop de petite et moyenne taille, oui. Dans le benchmark Elanis, une application Wails vide était 30 à 40 fois plus petite qu'une application Electron (benchmark Elanis, 2026), et vous obtenez un backend Go avec des bindings typés. Electron reste préférable quand vous avez besoin d'un rendu Chromium identique ou de modules natifs Node.

Wails consomme-t-il moins de mémoire qu'Electron ?

Cela dépend de l'OS. Dans le même benchmark, Wails utilisait environ 100 MB contre 369 MB pour Electron sous macOS, et 360 MB contre 586 MB sous Linux. Sous Windows, il en utilisait davantage, environ 323 MB contre 278 MB, probablement parce que WebView2 s'appuie sur le moteur Microsoft Edge, basé sur Chromium, et exécute ses propres processus de navigateur.

Wails est-il prêt pour la production ?

Wails v2 est la version stable, avec la v2.14.0 publiée le 10 août 2026 (versions Wails, 2026). Des applications comme Tiny RDM reposent dessus. Wails v3 est en bêta. Sa documentation indique que des applications l'utilisent déjà en production, mais conseille de tester minutieusement avant tout déploiement.

Les applications Wails fonctionnent-elles sous Windows 10 ?

Oui, à condition que le WebView2 Runtime soit installé. Microsoft indique que la grande majorité des appareils Windows 10 en disposent déjà (Microsoft Learn, 2026). Pour les autres, Wails peut intégrer un bootstrapper ou télécharger le runtime au moment de l'installation grâce au flag de build -webview2.

Puis-je conserver mon frontend React en passant à Wails ?

Oui. Wails sert n'importe quel frontend web compilé à partir de fichiers intégrés au binaire Go, donc React, Vue, Svelte et HTML simple fonctionnent tous. Ce qui change, c'est la façon dont le frontend communique avec le backend. Les appels IPC deviennent des imports de fonctions générées, et les messages push deviennent des événements runtime.

Sources

• Elanis, web-to-desktop-framework-comparison (mis à jour le 2026-09-04)
• Wails, Introduction
• Wails sur GitHub
• Wails, How does it work?
• Version Wails v2.14.0
• Version Wails v3.0.0-beta.25
• Wails v3, Migrating from v2
• Wails v3, Binding methods
• Référence de la CLI Wails
• Guide de signature Wails
• Guide Windows de Wails
• Guide Linux de Wails
• Distributions Linux prises en charge par Wails
• Issue Wails #4985, fenêtre vide sous Linux X11 avec Nvidia
• Vitrine Wails
• Tiny RDM
• Microsoft Learn, Distribute your app and the WebView2 Runtime
• Documentation Electron
• Electron, Process model
• Electron, Release timelines
• Calendrier des versions Electron
• Electron, Security checklist
• Vitrine des applications Electron
• Tauri, Start
• Annonce de Tauri 2.0 (2024)