5 alternatives légères à Electron

Cinq alternatives légères à Electron méritent qu’on s’y intéresse. tinyjs, Electrobun, Neutralinojs et Wails affichent votre frontend dans la webview fournie par le système d’exploitation. Perry, lui, compile TypeScript en une application native qui dessine de véritables widgets de la plateforme, sans aucune webview.

Vous disposez d’un frontend React ou Svelte qui fonctionne bien. Pourtant, l’installeur d’un petit utilitaire construit dessus est plus volumineux que la plupart des applications installées à côté.

Chaque application Electron embarque son propre Chromium et son propre Node.js. Chaque installation transporte donc un moteur de navigateur complet, et chaque application en cours d’exécution en paie le prix en espace disque et en mémoire. Cet article compare cinq alternatives selon quatre critères identiques : le mode de rendu, le langage du backend, les plateformes desktop prises en charge et le profil de développeurs visé.

Pourquoi les développeurs cherchent-ils des alternatives à Electron ?

La plupart des alternatives à Electron n’embarquent pas Chromium. Elles s’appuient sur la webview déjà fournie par l’OS, ce qui réduit considérablement la taille des applications. La contrepartie, c’est la cohérence du rendu. Votre application s’exécute sur WebKit sous macOS, sur WebView2 sous Windows et sur WebKitGTK sous Linux. Les cas limites se comportent donc comme lorsque vous déployez un même site sur Safari et sur Chrome.

Deux options bien connues ne figurent pas parmi les cinq présentées ci-dessous. Tauri associe la webview système à un backend Rust. Deno Desktop construit des applications desktop sur le runtime Deno.

Le tableau ci-dessous compare les cinq alternatives à Electron selon le moteur de rendu, le langage du backend, les plateformes desktop et la taille annoncée :

tinyjs : un backend JavaScript sans aucun port ouvert

tinyjs exécute un backend JavaScript sur txiki.js et affiche votre page dans la webview propre à la plateforme : WebKit sous macOS, WebView2 sous Windows et WebKitGTK sous Linux. La page et le backend communiquent via un socket Unix (un named pipe sous Windows). L’application n’ouvre donc jamais de port réseau local.

• Backend : txiki.js (QuickJS et libuv), avec accès aux fichiers, aux processus, aux sockets, à la FFI et à SQLite. Node n’est pas requis à l’exécution.
• Plateformes : le dépôt cible macOS, Windows et Linux, et le site du projet présente macOS comme plateforme principale. Les builds doivent être réalisés sur l’OS ciblé. tinyjs build produit un bundle signé et tinyjs notarize le soumet à la notarisation d’Apple.
• Taille : tinyjs annonce environ 6 Mo pour une application livrée, dont 5,6 Mo pour le runtime txiki.js.

tinyjs new myapp --template react-ts
cd myapp
tinyjs dev
tinyjs build

Le backend exporte un objet api, dont la page appelle les méthodes par leur nom :

// src/backend/main.js
export const api = {
  greet: async ({ user }) => `Welcome, ${user}`,
};

// in the page
const message = await tiny.api.call('greet', { user });

tinyjs prévient que c’est sous Linux que le rendu diffère le plus. Les codecs multimédias dépendent des plugins GStreamer installés, et la sortie Web Audio peut grésiller sous WebKitGTK. Pour qui : les développeurs JavaScript qui veulent écrire toute l’application, backend compris, dans un seul langage.

Electrobun : un processus principal en TypeScript ou en langage compilé

Electrobun effectue le rendu par défaut avec la webview système. Son processus principal exécute du TypeScript sur Cottontail (ou Bun), mais vous pouvez aussi l’écrire en Zig, Rust, Go ou Odin. Il cible macOS, Windows et Linux.

• Moteur de rendu : la webview système par défaut. Vous pouvez embarquer Chromium via CEF lorsqu’un rendu identique sur toutes les plateformes compte davantage que la taille du téléchargement.
• Backend : Cottontail, que la version 2.0 présente comme un runtime JavaScript écrit en Zig et reposant sur JavaScriptCore.
• Taille : Electrobun annonce, pour un hello world compressé sous macOS ARM64, 1,28 Mio avec un processus principal natif et environ 15 Mio avec Cottontail.
• Distribution : la signature de code, les mises à jour différentielles et les installeurs pour chaque OS sont intégrés. Le package est distribué sous licence MIT sur npm.

npx electrobun init

import { BrowserWindow } from "electrobun/main";

new BrowserWindow({
  title: "Inventory",
  url: "views://mainview/index.html",
  frame: { width: 1024, height: 720 },
});

Le schéma views:// charge une vue embarquée dans votre projet. Si vous utilisez la CLI Hutch d’Electrobun, hutch electrobun init génère le même projet. Pour qui : les équipes qui veulent conserver la séparation main/renderer d’Electron dans un package beaucoup plus léger.

Neutralinojs : des applications côté page, sans backend généraliste

Neutralinojs effectue le rendu dans la webview de l’OS et ne dispose d’aucun processus backend JavaScript généraliste. Votre code s’exécute dans la page et appelle une API native intégrée. Sa documentation confirme qu’aucun Chromium n’est livré avec l’application. Neutralinojs s’appuie sur la webview fournie par l’OS, par exemple WebKitGTK sous Linux.

• Backend : la page accède à la couche native via une bibliothèque cliente. D’après le dépôt GitHub de Neutralinojs, les appels natifs transitent par un WebSocket, et un serveur statique intégré sert les fichiers du frontend. Pour la logique que l’API ne couvre pas, vous pouvez écrire des extensions dans n’importe quel langage et les connecter via IPC.
• Plateformes : Linux, Windows, macOS et Web. La page des releases indique la v6.10.0 comme dernière version.

Pour qui : les petits utilitaires dont les besoins restent dans le périmètre de l’API intégrée (accès aux fichiers, exécution de commandes, boîtes de dialogue).

Perry : des widgets natifs, pas de webview

Perry n’est pas un wrapper de webview. Il compile TypeScript en amont (AOT) via LLVM en un exécutable natif qui dessine de véritables widgets de la plateforme : AppKit sous macOS, Win32 sous Windows et GTK4 sous Linux. Perry cible également le mobile, les montres connectées et la TV.

• Backend : il n’y a pas de backend distinct. L’application entière est du TypeScript compilé en code machine, et le runtime de Perry est lié au binaire lorsque le programme en a besoin.
• Limites : Perry compile un sous-ensemble pragmatique de TypeScript. Sa page des limitations exclut eval() et tout autre code dynamique, et ne mentionne qu’une prise en charge partielle des décorateurs. Certains packages npm ne compilent pas. Pour la compatibilité avec les packages npm JavaScript, Perry propose un runtime V8 optionnel via --enable-js-runtime.
• Taille : le dépôt de Perry indique environ 34 Ko pour un hello world qui se contente d’afficher des constantes. Dès qu’un programme utilise le runtime (boucles, JSON, async), comptez quelques Mo, soit environ 5,5 Mo sous macOS arm64.

perry doctor
perry check ./src
perry compile main.ts -o myapp

perry doctor vérifie que le compilateur, l’éditeur de liens et le SDK de la plateforme sont installés. perry check signale le code qui ne pourra pas être compilé nativement. Perry n’a pas de DOM : le code frontend qui en dépend ne peut donc pas être repris tel quel. Pour qui : les développeurs TypeScript prêts à réécrire l’interface pour bénéficier de contrôles natifs.

Wails : backend Go, webview système

Wails associe un backend Go à la webview de l’OS. Les développeurs Go conservent l’outillage frontend web qu’ils utilisent déjà. Le rendu est assuré par la WebView propre à chaque plateforme, si bien qu’aucun moteur de navigateur n’est embarqué. Wails v3.0.0 est sortie le 26 octobre 2026.

• Moteur de rendu : WebView2 sous Windows et WebKit sous macOS. Depuis la v3.0.0, Linux utilise par défaut GTK4 avec WebKitGTK 6.0. L’ancienne pile GTK3 reste disponible via -tags gtk3 jusqu’à la v3.1.
• Statut : la v3.0 est la branche stable actuelle, et la v2 reçoit toujours les mises à jour critiques. La prise en charge d’iOS et d’Android dans la v3 est expérimentale et n’entre pas dans l’engagement de stabilité. De nouvelles versions sortent régulièrement.
• Taille : la page Why Wails fait état de binaires d’environ 15 Mo.

go install github.com/wailsapp/wails/v3/cmd/wails3@latest
wails3 setup

Pour qui : les équipes dont la logique backend est déjà écrite en Go.

Quelle alternative à Electron choisir ?

Le bon choix dépend d’abord du langage que vous souhaitez utiliser côté backend, puis du degré de variation de rendu que vous êtes prêt à accepter :

• JavaScript de bout en bout : tinyjs.
• Processus principal en TypeScript, avec Chromium embarqué en option : Electrobun.
• Go : Wails.
• Une application qui n’a besoin que d’une API native intégrée : Neutralinojs.
• Des contrôles natifs plutôt qu’une interface web : Perry, seule option des cinq dans ce cas.

Avant de vous engager, développez un hello world avec vos deux candidats favoris. Exécutez ensuite votre véritable frontend dans la webview de chaque OS ciblé.

FAQ

Les utilisateurs Windows doivent-ils installer WebView2 pour exécuter les applications conçues avec ces outils ?

En général, non. Le runtime WebView2 Evergreen est préinstallé sur tous les appareils Windows 11, et Microsoft l'a déployé sur la plupart des appareils Windows 10 à partir de janvier 2023, y compris les machines gérées et jointes à un domaine. Un petit nombre de machines Windows 10 en sont toutefois encore dépourvues. Microsoft recommande donc que votre installeur vérifie la présence du runtime et le déploie s'il est absent, même si vous utilisez le mode Evergreen.

Puis-je réutiliser un frontend React existant avec Perry ?

Seulement en partie, et uniquement à titre expérimental. Perry n'a pas de DOM, mais le projet distinct perry-react fournit un moteur de rendu compatible React. Un bloc packageAliases dans package.json redirige les imports react et react-dom vers perry-react, et les éléments JSX sont associés à des widgets natifs : div devient par exemple VStack, et button devient Button. Le projet se présente comme une preuve de concept de Phase 1 ciblant macOS, avec iOS, Android, GTK4 et Win32 prévus par la suite. En Phase 1, les instances d'un même composant partagent l'état de leurs hooks. Le style via className n'est pas pris en charge (seules les props style en ligne le sont). Enfin, les bibliothèques qui dépendent du DOM ou de className, comme MUI ou React Router, ne fonctionnent pas.

Lesquelles de ces alternatives à Electron permettent aussi de créer des applications mobiles ?

Perry cible le mobile : il compile le même code TypeScript pour iOS et Android, ainsi que pour watchOS et la TV. tinyjs indique ne prendre en charge ni iOS ni Android et se présente comme un runtime desktop. Neutralinojs mentionne Linux, Windows, macOS et Web comme plateformes. Wails v3 propose une prise en charge expérimentale d'iOS et d'Android, qui n'est pas encore couverte par son engagement de stabilité. Si vous voulez une application à base de webview qui tourne aussi sur smartphone, Tauri 2 prend en charge iOS et Android en plus du desktop.

Que doivent installer les utilisateurs Linux pour exécuter une application utilisant la webview système ?

Une bibliothèque WebKitGTK, car ces outils utilisent la webview du système au lieu d'en embarquer une. Les exemples de tinyjs listent libwebkit2gtk-4.1-0 parmi les prérequis Linux. Wails v3.0 utilise par défaut GTK4 avec WebKitGTK 6.0. La prise en charge de l'audio et de la vidéo dépend des plugins GStreamer installés sur la machine. Testez donc la lecture multimédia sur chaque distribution Linux que vous comptez prendre en charge.